* [PATCH 00/62] arm-soc randconfig fixes
@ 2014-03-19 19:28 ` Arnd Bergmann
0 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:28 UTC (permalink / raw)
To: linux-arm-kernel
Hi everyone,
This is my much too long series of mostly trivial build for ARM platform
code. It's about a third of the total set of patches I have in a local
tree that I use for build testing randconfig kernels. Most of the other
patches are for device drivers, but there is also a significant chunk
for ARM architecture code, and a few things that are controversial or
not yet properly fixed.
I'd like to put all or most of these into a branch in arm-soc for
the coming merge window. Acks are very much appreciated, as as
Naks when I got something wrong. Everything I don't hear back
from I will assume is ok and put in.
Statistically speaking, I probably made a couple of mistakes here,
so please have a look if you find the time.
Arnd Bergmann (62):
ARM: at91: split out at91x40 into a top-level option
ARM: at91: don't provide dt init code for at91x40
ARM: at91: export sam9_smc interfaces
ARM: at91: fix broken "if () else" statement
ARM: at91: sama5 always uses DT
ARM: davinci: export da8xx_syscfg0_base
ARM: davinci: make dm644x-evm phy fixup conditional
ARM: davinci: use explicit 'select' for DA850_EVM
ARM: efm32: allow uncompress debug output
ARM: efm32: select AUTO_ZRELADDR
ARM: ep93xx: export ep93xx_chip_revision
ARM: hisi: fix building without CONFIG_HOTPLUG_CPU
ARM: hisi: select HAVE_ARM_SCU only for SMP
ARM: imx: imx6q_set_lpm is only defined for CONFIG_PM=y
ARM: ixp4xx/omixp: always include linux/leds.h
ARM: ixp4xx: avoid use of PCIBIOS_MIN_MEM in io.h
ARM: ixp4xx: fix gpio rework
ARM: ks8695/og: make PCI setup conditional
ARM: lpc32xx: export lpc32xx_return_iram_size
ARM: msm: add missing include of linux/module.h
ARM: msm: avoid calling debug_ll_addr on !MMU
ARM: msm: export legacy DMA interfaces
ARM: omap1: fix building without 32K_TIMER
ARM: omap1: select I2C where needed for PMIC
ARM: mvebu: add missing header
ARM: mvebu: don't select CONFIG_NEON
ARM: orion5x: make dns323 independent of PHY support
ARM: pxa: FB_W100 must be built-in
ARM: pxa: don't "select" SMC91X on MACH_XCEP
ARM: pxa: enable pxafb unconditionally for some boards
ARM: pxa: fix colibri build
ARM: pxa: fix pxa_ssp_* declarations
ARM: pxa: remove broken balloon3_gpio_vbus reference
ARM: pxa: select I2C_GPIO only if I2C is on
ARM: pxa: trizeps4 and trizeps4wl use the same file
ARM: rpc: autoselect CPU_SA110
ARM: sa1100/pxa: fix MTD_XIP build
ARM: footbridge: don't build floppy code for addin mode
ARM: footbridge: fix build with PCI disabled
ARM: footbridge: make screen_info setup conditional
ARM: realview: fix sparsemem build
ARM: realview: use explicit core tile config options
ARM: integrator: only select pl01x if TTY is enabled
ARM: integrator: refine CPU selection
ARM: s3c24xx: MINI2440 needs I2C for EEPROM_AT24
ARM: s3c24xx: fix gta02 build error
ARM: s3c64xx: MACH_SMDK6400 needs HSMMC1
ARM: s3c64xx: select power domains only when used
ARM: s5p64x0: fix building with only one soc type
ARM: s5pv210: enable IDE support in MACH_TORBRECK
ARM: samsung: allow serial driver to be disabled
ARM: samsung: disable decompressor watchdog on exynos
ARM: samsung: fix SAMSUNG_PM_DEBUG Kconfig logic
ARM: samsung: select ATAGS where necessary
ARM: samsung: select CRC32 for SAMSUNG_PM_CHECK
ARM: samsung: select I2C where needed for PMIC
ARM: exynos: fix l2x0 saved regs handling
ARM: exynos: add missing include of linux/module.h
ARM: shmobile: ak4642 needs i2c support
ARM: shmobile: work around CONFIG_PHYLIB=m
ARM: sunxi: fix build for THUMB2_KERNEL
ARM: tegra: make debug_ll code build for ARMv6
arch/arm/Kconfig | 9 ++++-
arch/arm/Kconfig.debug | 2 +-
arch/arm/include/debug/tegra.S | 18 ++++-----
arch/arm/mach-at91/Kconfig | 23 +++++++++--
arch/arm/mach-at91/Kconfig.non_dt | 8 +---
arch/arm/mach-at91/at91sam9260_devices.c | 4 +-
arch/arm/mach-at91/sam9_smc.c | 3 ++
arch/arm/mach-at91/setup.c | 2 +-
arch/arm/mach-davinci/Kconfig | 7 +---
arch/arm/mach-davinci/board-dm644x-evm.c | 11 +++---
arch/arm/mach-davinci/devices-da8xx.c | 1 +
arch/arm/mach-ep93xx/core.c | 1 +
arch/arm/mach-exynos/common.c | 6 ++-
arch/arm/mach-exynos/cpuidle.c | 1 +
arch/arm/mach-footbridge/Kconfig | 2 +-
arch/arm/mach-footbridge/Makefile | 3 +-
arch/arm/mach-footbridge/cats-hw.c | 2 +
arch/arm/mach-hisi/Kconfig | 2 +-
arch/arm/mach-hisi/Makefile | 3 +-
arch/arm/mach-hisi/hotplug.c | 2 +
arch/arm/mach-imx/clk-imx6q.c | 3 +-
arch/arm/mach-imx/clk-imx6sl.c | 3 +-
arch/arm/mach-imx/cpuidle-imx6sl.c | 3 ++
arch/arm/mach-integrator/Kconfig | 19 ++++++++--
arch/arm/mach-ixp4xx/common.c | 6 +--
arch/arm/mach-ixp4xx/goramo_mlr.c | 7 ++++
arch/arm/mach-ixp4xx/include/mach/io.h | 3 +-
arch/arm/mach-ixp4xx/omixp-setup.c | 2 -
arch/arm/mach-ks8695/board-og.c | 3 +-
arch/arm/mach-lpc32xx/common.c | 1 +
arch/arm/mach-msm/dma.c | 3 ++
arch/arm/mach-msm/io.c | 2 +
arch/arm/mach-mvebu/Kconfig | 2 -
arch/arm/mach-mvebu/board-v7.c | 1 +
arch/arm/mach-omap1/Kconfig | 4 ++
arch/arm/mach-omap1/pm.c | 8 ++--
arch/arm/mach-orion5x/Kconfig | 1 -
arch/arm/mach-orion5x/dns323-setup.c | 2 +
arch/arm/mach-pxa/Kconfig | 10 +++--
arch/arm/mach-pxa/balloon3.c | 1 -
arch/arm/mach-pxa/colibri-evalboard.c | 1 +
arch/arm/mach-pxa/include/mach/mtd-xip.h | 7 ++--
arch/arm/mach-pxa/irq.c | 8 ++++
arch/arm/mach-realview/Kconfig | 57 ++++++++++++++++++++++++++++
arch/arm/mach-realview/include/mach/memory.h | 2 +
arch/arm/mach-s3c24xx/Kconfig | 3 +-
arch/arm/mach-s3c24xx/mach-gta02.c | 2 +-
arch/arm/mach-s3c64xx/Kconfig | 3 ++
arch/arm/mach-s3c64xx/irq-pm.c | 12 ++++--
arch/arm/mach-s5p64x0/common.c | 18 ++++++++-
arch/arm/mach-s5p64x0/common.h | 5 +--
arch/arm/mach-s5p64x0/irq-pm.c | 6 +++
arch/arm/mach-s5pv210/Kconfig | 1 +
arch/arm/mach-sa1100/include/mach/mtd-xip.h | 4 +-
arch/arm/mach-shmobile/Kconfig | 12 +++---
arch/arm/mach-shmobile/board-koelsch.c | 2 +-
arch/arm/mach-shmobile/board-lager.c | 2 +-
arch/arm/mach-sunxi/headsmp.S | 3 +-
arch/arm/mm/Kconfig | 30 +++++++--------
arch/arm/plat-samsung/Kconfig | 7 ++--
arch/arm/plat-samsung/init.c | 4 ++
drivers/video/Kconfig | 4 +-
include/linux/pxa2xx_ssp.h | 2 +-
63 files changed, 276 insertions(+), 113 deletions(-)
--
1.8.3.2
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Uwe Kleine-K?nig <kernel@pengutronix.de>
Cc: Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Shawn Guo <shawn.guo@freescale.com>
Cc: Krzysztof Halasa <khc@pm.waw.pl>
Cc: David Brown <davidb@codeaurora.org>
Cc: linux-omap at vger.kernel.org
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Simon Horman <horms@verge.net.au>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 01/62] ARM: at91: split out at91x40 into a top-level option
2014-03-19 19:28 ` Arnd Bergmann
(?)
@ 2014-03-19 19:28 ` Arnd Bergmann
2014-03-20 8:38 ` Nicolas Ferre
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:28 UTC (permalink / raw)
To: linux-arm-kernel
at91x40 is different from all the other at91 machines, and it is
impossible to build a kernel that works on both this SoC and
any of the others, even though it is possible to build a noMMU
kernel for any at91 machine.
By turning at91x40 into a separate top-level option, we explicitly
forbid enabling invalid configurations that include mutually exclusive
machines.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Andrew Victor <linux@maxim.org.za>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
---
arch/arm/mach-at91/Kconfig | 22 ++++++++++++++++++----
arch/arm/mach-at91/Kconfig.non_dt | 8 +-------
2 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index ae6617e..7209c5b 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -64,11 +64,22 @@ choice
prompt "Core type"
+config ARCH_AT91X40
+ bool "ARM7/ARM9 AT91X40"
+ depends on !MMU
+ select CPU_ARM7TDMI
+ select ARCH_USES_GETTIMEOFFSET
+ select MULTI_IRQ_HANDLER
+ select SPARSE_IRQ
+
+ help
+ Select this if you are using one of Atmel's AT91X40 SoC.
+
config SOC_SAM_V4_V5
- bool "ARM7/ARM9"
+ bool "ARM7/ARM9 AT91SAM9/AT91RM9200"
help
- Select this if you are using one of Atmel's AT91SAM9, AT91RM9200
- or AT91X40 SoC.
+ Select this if you are using one of Atmel's AT91SAM9 or
+ AT91RM9200 SoC.
config SOC_SAM_V7
bool "Cortex A5"
@@ -177,9 +188,12 @@ config SOC_AT91SAM9N12
Select this if you are using Atmel's AT91SAM9N12 SoC.
# ----------------------------------------------------------
+endif # SOC_SAM_V4_V5
+
+if SOC_SAM_V4_V5 || ARCH_AT91X40
source arch/arm/mach-at91/Kconfig.non_dt
-endif # SOC_SAM_V4_V5
+endif
comment "Generic Board Type"
diff --git a/arch/arm/mach-at91/Kconfig.non_dt b/arch/arm/mach-at91/Kconfig.non_dt
index 1f73e9b..44ace32 100644
--- a/arch/arm/mach-at91/Kconfig.non_dt
+++ b/arch/arm/mach-at91/Kconfig.non_dt
@@ -5,6 +5,7 @@ config HAVE_AT91_DATAFLASH_CARD
choice
prompt "Atmel AT91 Processor Devices for non DT boards"
+ depends on !ARCH_AT91X40
config ARCH_AT91_NONE
bool "None"
@@ -39,13 +40,6 @@ config ARCH_AT91SAM9G45
select SOC_AT91SAM9G45
select AT91_USE_OLD_CLK
-config ARCH_AT91X40
- bool "AT91x40"
- depends on !MMU
- select ARCH_USES_GETTIMEOFFSET
- select MULTI_IRQ_HANDLER
- select SPARSE_IRQ
-
endchoice
config ARCH_AT91SAM9G20
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread
* [PATCH 01/62] ARM: at91: split out at91x40 into a top-level option
2014-03-19 19:28 ` [PATCH 01/62] ARM: at91: split out at91x40 into a top-level option Arnd Bergmann
@ 2014-03-20 8:38 ` Nicolas Ferre
2014-03-21 15:46 ` Arnd Bergmann
0 siblings, 1 reply; 205+ messages in thread
From: Nicolas Ferre @ 2014-03-20 8:38 UTC (permalink / raw)
To: linux-arm-kernel
On 19/03/2014 20:28, Arnd Bergmann :
> at91x40 is different from all the other at91 machines, and it is
> impossible to build a kernel that works on both this SoC and
> any of the others, even though it is possible to build a noMMU
> kernel for any at91 machine.
>
> By turning at91x40 into a separate top-level option, we explicitly
> forbid enabling invalid configurations that include mutually exclusive
> machines.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Andrew Victor <linux@maxim.org.za>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
I added below little modifications to the comments, now that the AT91X40
is another entry.
Otherwise:
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> ---
> arch/arm/mach-at91/Kconfig | 22 ++++++++++++++++++----
> arch/arm/mach-at91/Kconfig.non_dt | 8 +-------
> 2 files changed, 19 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
> index ae6617e..7209c5b 100644
> --- a/arch/arm/mach-at91/Kconfig
> +++ b/arch/arm/mach-at91/Kconfig
> @@ -64,11 +64,22 @@ choice
>
> prompt "Core type"
>
> +config ARCH_AT91X40
> + bool "ARM7/ARM9 AT91X40"
AT91X40 is an ARM7TDMI, so you can remove the alternative here:
+ bool "ARM7 AT91X40"
seems better.
> + depends on !MMU
> + select CPU_ARM7TDMI
> + select ARCH_USES_GETTIMEOFFSET
> + select MULTI_IRQ_HANDLER
> + select SPARSE_IRQ
> +
> + help
> + Select this if you are using one of Atmel's AT91X40 SoC.
> +
> config SOC_SAM_V4_V5
> - bool "ARM7/ARM9"
> + bool "ARM7/ARM9 AT91SAM9/AT91RM9200"
Now that we have only ARM9s here, remove the alternative:
+ bool "ARM9 AT91SAM9/AT91RM9200"
> help
> - Select this if you are using one of Atmel's AT91SAM9, AT91RM9200
> - or AT91X40 SoC.
> + Select this if you are using one of Atmel's AT91SAM9 or
> + AT91RM9200 SoC.
>
> config SOC_SAM_V7
> bool "Cortex A5"
> @@ -177,9 +188,12 @@ config SOC_AT91SAM9N12
> Select this if you are using Atmel's AT91SAM9N12 SoC.
>
> # ----------------------------------------------------------
> +endif # SOC_SAM_V4_V5
> +
>
> +if SOC_SAM_V4_V5 || ARCH_AT91X40
> source arch/arm/mach-at91/Kconfig.non_dt
> -endif # SOC_SAM_V4_V5
> +endif
>
> comment "Generic Board Type"
>
> diff --git a/arch/arm/mach-at91/Kconfig.non_dt b/arch/arm/mach-at91/Kconfig.non_dt
> index 1f73e9b..44ace32 100644
> --- a/arch/arm/mach-at91/Kconfig.non_dt
> +++ b/arch/arm/mach-at91/Kconfig.non_dt
> @@ -5,6 +5,7 @@ config HAVE_AT91_DATAFLASH_CARD
>
> choice
> prompt "Atmel AT91 Processor Devices for non DT boards"
> + depends on !ARCH_AT91X40
>
> config ARCH_AT91_NONE
> bool "None"
> @@ -39,13 +40,6 @@ config ARCH_AT91SAM9G45
> select SOC_AT91SAM9G45
> select AT91_USE_OLD_CLK
>
> -config ARCH_AT91X40
> - bool "AT91x40"
> - depends on !MMU
> - select ARCH_USES_GETTIMEOFFSET
> - select MULTI_IRQ_HANDLER
> - select SPARSE_IRQ
> -
> endchoice
>
> config ARCH_AT91SAM9G20
>
--
Nicolas Ferre
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 01/62] ARM: at91: split out at91x40 into a top-level option
2014-03-20 8:38 ` Nicolas Ferre
@ 2014-03-21 15:46 ` Arnd Bergmann
0 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-21 15:46 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 20 March 2014, Nicolas Ferre wrote:
> On 19/03/2014 20:28, Arnd Bergmann :
> > at91x40 is different from all the other at91 machines, and it is
> > impossible to build a kernel that works on both this SoC and
> > any of the others, even though it is possible to build a noMMU
> > kernel for any at91 machine.
> >
> > By turning at91x40 into a separate top-level option, we explicitly
> > forbid enabling invalid configurations that include mutually exclusive
> > machines.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Andrew Victor <linux@maxim.org.za>
> > Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
>
> I added below little modifications to the comments, now that the AT91X40
> is another entry.
>
> Otherwise:
>
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Changed now, thanks for the suggestion!
Arnd
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 02/62] ARM: at91: don't provide dt init code for at91x40
2014-03-19 19:28 ` Arnd Bergmann
(?)
(?)
@ 2014-03-19 19:28 ` Arnd Bergmann
2014-03-20 8:40 ` Nicolas Ferre
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:28 UTC (permalink / raw)
To: linux-arm-kernel
at91x40 has no support for device tree, but Kconfig allows
us to enable CONFIG_OF anyway, causing a link error in the
at91 reset controller initialization.
The easiest fix is to adapt the existing #ifdef to omit
the broken code on at91x40 where it is never called anyway.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Andrew Victor <linux@maxim.org.za>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
---
arch/arm/mach-at91/setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
index f7ca97b..f7a07a5 100644
--- a/arch/arm/mach-at91/setup.c
+++ b/arch/arm/mach-at91/setup.c
@@ -351,7 +351,7 @@ void __init at91_ioremap_matrix(u32 base_addr)
panic("Impossible to ioremap at91_matrix_base\n");
}
-#if defined(CONFIG_OF)
+#if defined(CONFIG_OF) && !defined(CONFIG_ARCH_AT91X40)
static struct of_device_id rstc_ids[] = {
{ .compatible = "atmel,at91sam9260-rstc", .data = at91sam9_alt_restart },
{ .compatible = "atmel,at91sam9g45-rstc", .data = at91sam9g45_restart },
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 02/62] ARM: at91: don't provide dt init code for at91x40
2014-03-19 19:28 ` [PATCH 02/62] ARM: at91: don't provide dt init code for at91x40 Arnd Bergmann
@ 2014-03-20 8:40 ` Nicolas Ferre
0 siblings, 0 replies; 205+ messages in thread
From: Nicolas Ferre @ 2014-03-20 8:40 UTC (permalink / raw)
To: linux-arm-kernel
On 19/03/2014 20:28, Arnd Bergmann :
> at91x40 has no support for device tree, but Kconfig allows
> us to enable CONFIG_OF anyway, causing a link error in the
> at91 reset controller initialization.
>
> The easiest fix is to adapt the existing #ifdef to omit
> the broken code on at91x40 where it is never called anyway.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Andrew Victor <linux@maxim.org.za>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Yes, simple and does the trick:
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> ---
> arch/arm/mach-at91/setup.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
> index f7ca97b..f7a07a5 100644
> --- a/arch/arm/mach-at91/setup.c
> +++ b/arch/arm/mach-at91/setup.c
> @@ -351,7 +351,7 @@ void __init at91_ioremap_matrix(u32 base_addr)
> panic("Impossible to ioremap at91_matrix_base\n");
> }
>
> -#if defined(CONFIG_OF)
> +#if defined(CONFIG_OF) && !defined(CONFIG_ARCH_AT91X40)
> static struct of_device_id rstc_ids[] = {
> { .compatible = "atmel,at91sam9260-rstc", .data = at91sam9_alt_restart },
> { .compatible = "atmel,at91sam9g45-rstc", .data = at91sam9g45_restart },
>
--
Nicolas Ferre
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 03/62] ARM: at91: export sam9_smc interfaces
2014-03-19 19:28 ` Arnd Bergmann
` (2 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-20 8:51 ` Nicolas Ferre
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
The pata_at91 driver uses interfaces defined in the sam9_smc
platform code. Since the pata driver can be a loadable module,
we have to export those symbols in order to link cleanly.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Andrew Victor <linux@maxim.org.za>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
---
arch/arm/mach-at91/sam9_smc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-at91/sam9_smc.c b/arch/arm/mach-at91/sam9_smc.c
index b26156b..826315a 100644
--- a/arch/arm/mach-at91/sam9_smc.c
+++ b/arch/arm/mach-at91/sam9_smc.c
@@ -36,6 +36,7 @@ void sam9_smc_write_mode(int id, int cs,
{
sam9_smc_cs_write_mode(AT91_SMC_CS(id, cs), config);
}
+EXPORT_SYMBOL_GPL(sam9_smc_write_mode);
static void sam9_smc_cs_configure(void __iomem *base,
struct sam9_smc_config *config)
@@ -69,6 +70,7 @@ void sam9_smc_configure(int id, int cs,
{
sam9_smc_cs_configure(AT91_SMC_CS(id, cs), config);
}
+EXPORT_SYMBOL_GPL(sam9_smc_configure);
static void sam9_smc_cs_read_mode(void __iomem *base,
struct sam9_smc_config *config)
@@ -84,6 +86,7 @@ void sam9_smc_read_mode(int id, int cs,
{
sam9_smc_cs_read_mode(AT91_SMC_CS(id, cs), config);
}
+EXPORT_SYMBOL_GPL(sam9_smc_read_mode);
static void sam9_smc_cs_read(void __iomem *base,
struct sam9_smc_config *config)
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 03/62] ARM: at91: export sam9_smc interfaces
2014-03-19 19:29 ` [PATCH 03/62] ARM: at91: export sam9_smc interfaces Arnd Bergmann
@ 2014-03-20 8:51 ` Nicolas Ferre
0 siblings, 0 replies; 205+ messages in thread
From: Nicolas Ferre @ 2014-03-20 8:51 UTC (permalink / raw)
To: linux-arm-kernel
On 19/03/2014 20:29, Arnd Bergmann :
> The pata_at91 driver uses interfaces defined in the sam9_smc
> platform code. Since the pata driver can be a loadable module,
> we have to export those symbols in order to link cleanly.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Andrew Victor <linux@maxim.org.za>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
SMC may change in the near future (Cf. Jean-Jacques' patches sent some
weeks ago). But I do not think this patch conflicts with the ongoing
initiative...
So:
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> ---
> arch/arm/mach-at91/sam9_smc.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/mach-at91/sam9_smc.c b/arch/arm/mach-at91/sam9_smc.c
> index b26156b..826315a 100644
> --- a/arch/arm/mach-at91/sam9_smc.c
> +++ b/arch/arm/mach-at91/sam9_smc.c
> @@ -36,6 +36,7 @@ void sam9_smc_write_mode(int id, int cs,
> {
> sam9_smc_cs_write_mode(AT91_SMC_CS(id, cs), config);
> }
> +EXPORT_SYMBOL_GPL(sam9_smc_write_mode);
>
> static void sam9_smc_cs_configure(void __iomem *base,
> struct sam9_smc_config *config)
> @@ -69,6 +70,7 @@ void sam9_smc_configure(int id, int cs,
> {
> sam9_smc_cs_configure(AT91_SMC_CS(id, cs), config);
> }
> +EXPORT_SYMBOL_GPL(sam9_smc_configure);
>
> static void sam9_smc_cs_read_mode(void __iomem *base,
> struct sam9_smc_config *config)
> @@ -84,6 +86,7 @@ void sam9_smc_read_mode(int id, int cs,
> {
> sam9_smc_cs_read_mode(AT91_SMC_CS(id, cs), config);
> }
> +EXPORT_SYMBOL_GPL(sam9_smc_read_mode);
>
> static void sam9_smc_cs_read(void __iomem *base,
> struct sam9_smc_config *config)
>
--
Nicolas Ferre
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 04/62] ARM: at91: fix broken "if () else" statement
2014-03-19 19:28 ` Arnd Bergmann
` (3 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-20 8:56 ` Nicolas Ferre
2014-03-20 13:16 ` Jean-Christophe PLAGNIOL-VILLARD
-1 siblings, 2 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
If CONFIG_PATA_AT91 is disabled, the code in at91_add_device_cf
is turned into invalid C statements due to the lack of an
expression before the 'else' clause.
This moves the first half of the condition inside of the #ifdef,
which seems to be what the author intended.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Andrew Victor <linux@maxim.org.za>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
---
arch/arm/mach-at91/at91sam9260_devices.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-at91/at91sam9260_devices.c b/arch/arm/mach-at91/at91sam9260_devices.c
index 2ae7715..4222a7d 100644
--- a/arch/arm/mach-at91/at91sam9260_devices.c
+++ b/arch/arm/mach-at91/at91sam9260_devices.c
@@ -1263,13 +1263,13 @@ void __init at91_add_device_cf(struct at91_cf_data *data)
at91_set_A_periph(AT91_PIN_PC10, 0); /* CFRNW */
at91_set_A_periph(AT91_PIN_PC15, 1); /* NWAIT */
- if (data->flags & AT91_CF_TRUE_IDE)
#if defined(CONFIG_PATA_AT91) || defined(CONFIG_PATA_AT91_MODULE)
+ if (data->flags & AT91_CF_TRUE_IDE)
pdev->name = "pata_at91";
+ else
#else
#warning "board requires AT91_CF_TRUE_IDE: enable pata_at91"
#endif
- else
pdev->name = "at91_cf";
platform_device_register(pdev);
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 04/62] ARM: at91: fix broken "if () else" statement
2014-03-19 19:29 ` [PATCH 04/62] ARM: at91: fix broken "if () else" statement Arnd Bergmann
@ 2014-03-20 8:56 ` Nicolas Ferre
2014-03-20 13:16 ` Jean-Christophe PLAGNIOL-VILLARD
1 sibling, 0 replies; 205+ messages in thread
From: Nicolas Ferre @ 2014-03-20 8:56 UTC (permalink / raw)
To: linux-arm-kernel
On 19/03/2014 20:29, Arnd Bergmann :
> If CONFIG_PATA_AT91 is disabled, the code in at91_add_device_cf
> is turned into invalid C statements due to the lack of an
> expression before the 'else' clause.
>
> This moves the first half of the condition inside of the #ifdef,
> which seems to be what the author intended.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Andrew Victor <linux@maxim.org.za>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> ---
> arch/arm/mach-at91/at91sam9260_devices.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-at91/at91sam9260_devices.c b/arch/arm/mach-at91/at91sam9260_devices.c
> index 2ae7715..4222a7d 100644
> --- a/arch/arm/mach-at91/at91sam9260_devices.c
> +++ b/arch/arm/mach-at91/at91sam9260_devices.c
> @@ -1263,13 +1263,13 @@ void __init at91_add_device_cf(struct at91_cf_data *data)
> at91_set_A_periph(AT91_PIN_PC10, 0); /* CFRNW */
> at91_set_A_periph(AT91_PIN_PC15, 1); /* NWAIT */
>
> - if (data->flags & AT91_CF_TRUE_IDE)
> #if defined(CONFIG_PATA_AT91) || defined(CONFIG_PATA_AT91_MODULE)
> + if (data->flags & AT91_CF_TRUE_IDE)
> pdev->name = "pata_at91";
> + else
> #else
> #warning "board requires AT91_CF_TRUE_IDE: enable pata_at91"
> #endif
> - else
> pdev->name = "at91_cf";
>
> platform_device_register(pdev);
>
--
Nicolas Ferre
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 04/62] ARM: at91: fix broken "if () else" statement
2014-03-19 19:29 ` [PATCH 04/62] ARM: at91: fix broken "if () else" statement Arnd Bergmann
2014-03-20 8:56 ` Nicolas Ferre
@ 2014-03-20 13:16 ` Jean-Christophe PLAGNIOL-VILLARD
2014-03-21 15:48 ` Arnd Bergmann
1 sibling, 1 reply; 205+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2014-03-20 13:16 UTC (permalink / raw)
To: linux-arm-kernel
On Mar 20, 2014, at 3:29 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> If CONFIG_PATA_AT91 is disabled, the code in at91_add_device_cf
> is turned into invalid C statements due to the lack of an
> expression before the 'else' clause.
>
> This moves the first half of the condition inside of the #ifdef,
> which seems to be what the author intended.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Andrew Victor <linux@maxim.org.za>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> ---
> arch/arm/mach-at91/at91sam9260_devices.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-at91/at91sam9260_devices.c b/arch/arm/mach-at91/at91sam9260_devices.c
> index 2ae7715..4222a7d 100644
> --- a/arch/arm/mach-at91/at91sam9260_devices.c
> +++ b/arch/arm/mach-at91/at91sam9260_devices.c
> @@ -1263,13 +1263,13 @@ void __init at91_add_device_cf(struct at91_cf_data *data)
> at91_set_A_periph(AT91_PIN_PC10, 0); /* CFRNW */
> at91_set_A_periph(AT91_PIN_PC15, 1); /* NWAIT */
>
> - if (data->flags & AT91_CF_TRUE_IDE)
> #if defined(CONFIG_PATA_AT91) || defined(CONFIG_PATA_AT91_MODULE)
> + if (data->flags & AT91_CF_TRUE_IDE)
I prefer if (IS_ENABLED())
> pdev->name = "pata_at91";
> + else
> #else
> #warning "board requires AT91_CF_TRUE_IDE: enable pata_at91?
but this means drop this warning
> #endif
> - else
> pdev->name = "at91_cf";
>
> platform_device_register(pdev);
> --
> 1.8.3.2
>
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 04/62] ARM: at91: fix broken "if () else" statement
2014-03-20 13:16 ` Jean-Christophe PLAGNIOL-VILLARD
@ 2014-03-21 15:48 ` Arnd Bergmann
0 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-21 15:48 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 20 March 2014, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On Mar 20, 2014, at 3:29 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > - if (data->flags & AT91_CF_TRUE_IDE)
> > #if defined(CONFIG_PATA_AT91) || defined(CONFIG_PATA_AT91_MODULE)
> > + if (data->flags & AT91_CF_TRUE_IDE)
> I prefer if (IS_ENABLED())
> > pdev->name = "pata_at91";
> > + else
> > #else
> > #warning "board requires AT91_CF_TRUE_IDE: enable pata_at91?
> but this means drop this warning
> > #endif
Good idea, thanks!
Arnd
>From ce916f429091f98cc53ee9cf11e6e02b4dc3dc25 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Thu, 13 Mar 2014 17:47:23 +0100
Subject: [PATCH] ARM: at91: fix broken "if () else" statement
If CONFIG_PATA_AT91 is disabled, the code in at91_add_device_cf
is turned into invalid C statements due to the lack of an
expression before the 'else' clause.
This moves the first half of the condition inside of the #ifdef,
which seems to be what the author intended.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Andrew Victor <linux@maxim.org.za>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
diff --git a/arch/arm/mach-at91/at91sam9260_devices.c b/arch/arm/mach-at91/at91sam9260_devices.c
index 2ae7715..33fa98d 100644
--- a/arch/arm/mach-at91/at91sam9260_devices.c
+++ b/arch/arm/mach-at91/at91sam9260_devices.c
@@ -1263,12 +1263,8 @@ void __init at91_add_device_cf(struct at91_cf_data *data)
at91_set_A_periph(AT91_PIN_PC10, 0); /* CFRNW */
at91_set_A_periph(AT91_PIN_PC15, 1); /* NWAIT */
- if (data->flags & AT91_CF_TRUE_IDE)
-#if defined(CONFIG_PATA_AT91) || defined(CONFIG_PATA_AT91_MODULE)
+ if (IS_ENABLED(CONFIG_PATA_AT91) && (data->flags & AT91_CF_TRUE_IDE)
pdev->name = "pata_at91";
-#else
-#warning "board requires AT91_CF_TRUE_IDE: enable pata_at91"
-#endif
else
pdev->name = "at91_cf";
^ permalink raw reply related [flat|nested] 205+ messages in thread
* [PATCH 05/62] ARM: at91: sama5 always uses DT
2014-03-19 19:28 ` Arnd Bergmann
` (4 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-20 8:57 ` Nicolas Ferre
2014-03-20 13:15 ` Jean-Christophe PLAGNIOL-VILLARD
-1 siblings, 2 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
It makes no sense for sama5 support to be enabled if we don't
also enable USE_OF. Making this automatic in Kconfig avoids
a possible randconfig conflict between the old and new clock
support code.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Andrew Victor <linux@maxim.org.za>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
---
arch/arm/mach-at91/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index 7209c5b..5ec1da1 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -57,6 +57,7 @@ config SOC_SAMA5
select GENERIC_CLOCKEVENTS
select MULTI_IRQ_HANDLER
select SPARSE_IRQ
+ select USE_OF
menu "Atmel AT91 System-on-Chip"
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 05/62] ARM: at91: sama5 always uses DT
2014-03-19 19:29 ` [PATCH 05/62] ARM: at91: sama5 always uses DT Arnd Bergmann
@ 2014-03-20 8:57 ` Nicolas Ferre
2014-03-20 13:15 ` Jean-Christophe PLAGNIOL-VILLARD
1 sibling, 0 replies; 205+ messages in thread
From: Nicolas Ferre @ 2014-03-20 8:57 UTC (permalink / raw)
To: linux-arm-kernel
On 19/03/2014 20:29, Arnd Bergmann :
> It makes no sense for sama5 support to be enabled if we don't
> also enable USE_OF. Making this automatic in Kconfig avoids
> a possible randconfig conflict between the old and new clock
> support code.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Andrew Victor <linux@maxim.org.za>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> ---
> arch/arm/mach-at91/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
> index 7209c5b..5ec1da1 100644
> --- a/arch/arm/mach-at91/Kconfig
> +++ b/arch/arm/mach-at91/Kconfig
> @@ -57,6 +57,7 @@ config SOC_SAMA5
> select GENERIC_CLOCKEVENTS
> select MULTI_IRQ_HANDLER
> select SPARSE_IRQ
> + select USE_OF
>
> menu "Atmel AT91 System-on-Chip"
>
>
--
Nicolas Ferre
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 05/62] ARM: at91: sama5 always uses DT
2014-03-19 19:29 ` [PATCH 05/62] ARM: at91: sama5 always uses DT Arnd Bergmann
2014-03-20 8:57 ` Nicolas Ferre
@ 2014-03-20 13:15 ` Jean-Christophe PLAGNIOL-VILLARD
1 sibling, 0 replies; 205+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2014-03-20 13:15 UTC (permalink / raw)
To: linux-arm-kernel
On Mar 20, 2014, at 3:29 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> It makes no sense for sama5 support to be enabled if we don't
> also enable USE_OF. Making this automatic in Kconfig avoids
> a possible randconfig conflict between the old and new clock
> support code.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Andrew Victor <linux@maxim.org.za>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
>
> ---
> arch/arm/mach-at91/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
> index 7209c5b..5ec1da1 100644
> --- a/arch/arm/mach-at91/Kconfig
> +++ b/arch/arm/mach-at91/Kconfig
> @@ -57,6 +57,7 @@ config SOC_SAMA5
> select GENERIC_CLOCKEVENTS
> select MULTI_IRQ_HANDLER
> select SPARSE_IRQ
> + select USE_OF
>
> menu "Atmel AT91 System-on-Chip"
>
> --
> 1.8.3.2
>
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base
2014-03-19 19:28 ` Arnd Bergmann
` (5 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-19 20:53 ` Sergei Shtylyov
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
The ohci-da8xx driver uses the DA8XX_SYSCFG0_VIRT macro to
access the CFGCHIP2 register for controlling its PHY.
The macro in turn relies on the da8xx_syscfg0_base global
variable. Since the OHCI driver can be a loadable module,
this requires the symbol to be exported from platform code.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: davinci-linux-open-source at linux.davincidsp.com
---
arch/arm/mach-davinci/devices-da8xx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
index 0486cdf..4da868a 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -66,6 +66,7 @@
#define DA850_DMA_MMCSD1_TX EDMA_CTLR_CHAN(1, 29)
void __iomem *da8xx_syscfg0_base;
+EXPORT_SYMBOL_GPL(da8xx_syscfg0_base); /* used by OHCI_HCD */
void __iomem *da8xx_syscfg1_base;
static struct plat_serial8250_port da8xx_serial0_pdata[] = {
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base
2014-03-19 19:29 ` [PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base Arnd Bergmann
@ 2014-03-19 20:53 ` Sergei Shtylyov
2014-03-19 20:21 ` Arnd Bergmann
0 siblings, 1 reply; 205+ messages in thread
From: Sergei Shtylyov @ 2014-03-19 20:53 UTC (permalink / raw)
To: linux-arm-kernel
On 03/19/2014 10:29 PM, Arnd Bergmann wrote:
> The ohci-da8xx driver uses the DA8XX_SYSCFG0_VIRT macro to
> access the CFGCHIP2 register for controlling its PHY.
> The macro in turn relies on the da8xx_syscfg0_base global
> variable. Since the OHCI driver can be a loadable module,
> this requires the symbol to be exported from platform code.
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Sekhar Nori <nsekhar@ti.com>
> Cc: Kevin Hilman <khilman@deeprootsystems.com>
> Cc: davinci-linux-open-source at linux.davincidsp.com
> ---
> arch/arm/mach-davinci/devices-da8xx.c | 1 +
> 1 file changed, 1 insertion(+)
> diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
> index 0486cdf..4da868a 100644
> --- a/arch/arm/mach-davinci/devices-da8xx.c
> +++ b/arch/arm/mach-davinci/devices-da8xx.c
> @@ -66,6 +66,7 @@
> #define DA850_DMA_MMCSD1_TX EDMA_CTLR_CHAN(1, 29)
>
> void __iomem *da8xx_syscfg0_base;
> +EXPORT_SYMBOL_GPL(da8xx_syscfg0_base); /* used by OHCI_HCD */
I have submitted such patch years ago and it was turned down. :-)
WBR, Sergei
^ permalink raw reply [flat|nested] 205+ messages in thread* [PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base
2014-03-19 20:53 ` Sergei Shtylyov
@ 2014-03-19 20:21 ` Arnd Bergmann
2014-03-19 22:36 ` Sergei Shtylyov
2014-03-20 9:24 ` Sekhar Nori
0 siblings, 2 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 20:21 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 19 March 2014 23:53:18 Sergei Shtylyov wrote:
> On 03/19/2014 10:29 PM, Arnd Bergmann wrote:
>
> > The ohci-da8xx driver uses the DA8XX_SYSCFG0_VIRT macro to
> > access the CFGCHIP2 register for controlling its PHY.
>
> > The macro in turn relies on the da8xx_syscfg0_base global
> > variable. Since the OHCI driver can be a loadable module,
> > this requires the symbol to be exported from platform code.
>
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Sekhar Nori <nsekhar@ti.com>
> > Cc: Kevin Hilman <khilman@deeprootsystems.com>
> > Cc: davinci-linux-open-source at linux.davincidsp.com
> > ---
> > arch/arm/mach-davinci/devices-da8xx.c | 1 +
> > 1 file changed, 1 insertion(+)
>
> > diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
> > index 0486cdf..4da868a 100644
> > --- a/arch/arm/mach-davinci/devices-da8xx.c
> > +++ b/arch/arm/mach-davinci/devices-da8xx.c
> > @@ -66,6 +66,7 @@
> > #define DA850_DMA_MMCSD1_TX EDMA_CTLR_CHAN(1, 29)
> >
> > void __iomem *da8xx_syscfg0_base;
> > +EXPORT_SYMBOL_GPL(da8xx_syscfg0_base); /* used by OHCI_HCD */
>
> I have submitted such patch years ago and it was turned down.
>
The question is whether there is anyone who would do this properly.
Both the OHCI and MUSB drivers use exactly one register (CFGCHIP2)
to control the clock, phy and host/gadget mode switch.
In the modern world, we'd probably want to have a clock driver and
a phy driver for these, based on a syscon driver.
In all honesty I don't see that happening on davinci.
A somewhat better approach would be to export a set of exported
functions to access the one register from the platform, e.g.
u32 da8xx_cfgchip2_get(void);
void da8xx_cfgchip2_set(u32);
That interface would still be a bit ugly, but much better than
what we have today, and easy to implement.
Arnd
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base
2014-03-19 20:21 ` Arnd Bergmann
@ 2014-03-19 22:36 ` Sergei Shtylyov
2014-03-20 6:42 ` Arnd Bergmann
2014-03-20 9:24 ` Sekhar Nori
1 sibling, 1 reply; 205+ messages in thread
From: Sergei Shtylyov @ 2014-03-19 22:36 UTC (permalink / raw)
To: linux-arm-kernel
On 03/19/2014 11:21 PM, Arnd Bergmann wrote:
>>> The ohci-da8xx driver uses the DA8XX_SYSCFG0_VIRT macro to
>>> access the CFGCHIP2 register for controlling its PHY.
>>> The macro in turn relies on the da8xx_syscfg0_base global
>>> variable. Since the OHCI driver can be a loadable module,
>>> this requires the symbol to be exported from platform code.
>>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>>> Cc: Sekhar Nori <nsekhar@ti.com>
>>> Cc: Kevin Hilman <khilman@deeprootsystems.com>
>>> Cc: davinci-linux-open-source at linux.davincidsp.com
>>> ---
>>> arch/arm/mach-davinci/devices-da8xx.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>> diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
>>> index 0486cdf..4da868a 100644
>>> --- a/arch/arm/mach-davinci/devices-da8xx.c
>>> +++ b/arch/arm/mach-davinci/devices-da8xx.c
>>> @@ -66,6 +66,7 @@
>>> #define DA850_DMA_MMCSD1_TX EDMA_CTLR_CHAN(1, 29)
>>>
>>> void __iomem *da8xx_syscfg0_base;
>>> +EXPORT_SYMBOL_GPL(da8xx_syscfg0_base); /* used by OHCI_HCD */
>> I have submitted such patch years ago and it was turned down.
I also had a pleasure of completing implementation of this driver and
submitting it back in 2009 when I was working for MontaVista. :-)
> The question is whether there is anyone who would do this properly.
Nobody cares, it seems. As you can imagine, I stopped to care enough after
being switched to other projects.
> Both the OHCI and MUSB drivers use exactly one register (CFGCHIP2)
The idea at the time was to just ioremap() this register but I was not
very eager.
There was no USB PHY driver subsystem yet.
> to control the clock, phy
Note that it only controls PHY clock (PLL) which could be covered by an
USB PHY driver.
> and host/gadget mode switch.
The main mode the USB 2.0 PHY should function now is OTG. The host/gadged
modes are forced overrides of the ID pin. Unfortunately, the board code has to
force host mode when host-only driver config is selected (these MUSB's
host/gadget only modes were removed at one point but got reintroduced again).
> In the modern world, we'd probably want to have a clock driver and
Not sure about the clock driver...
> a phy driver for these,
Yes, that's what the MUSB maintainer wants too. The issue is the driver
should somehow differ which USB controller it's bound too and do different
things depending on that (at least that's how it looks now). I'm not sure it's
possible, so probably should be rethought.
> based on a syscon driver.
I don't know what syscon is...
> In all honesty I don't see that happening on davinci.
I don't think people use USB 1.1 controllers these days, especially when
there is USB 2.0 in the same SoC. For MUSB, there were recent attempt to get
the DA8xx driver out of the broken state but it was turned down as well, IIRC,
since it didn't offer a PHY driver.
> A somewhat better approach would be to export a set of exported
> functions to access the one register from the platform, e.g.
> u32 da8xx_cfgchip2_get(void);
> void da8xx_cfgchip2_set(u32);
> That interface would still be a bit ugly, but much better than
> what we have today, and easy to implement.
I'm leaving this idea to Sekhar...
> Arnd
WBR, Sergei
^ permalink raw reply [flat|nested] 205+ messages in thread* [PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base
2014-03-19 22:36 ` Sergei Shtylyov
@ 2014-03-20 6:42 ` Arnd Bergmann
2014-03-20 9:36 ` Sekhar Nori
2014-03-20 16:20 ` Sergei Shtylyov
0 siblings, 2 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-20 6:42 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 20 March 2014 01:36:13 Sergei Shtylyov wrote:
> On 03/19/2014 11:21 PM, Arnd Bergmann wrote:
> > The question is whether there is anyone who would do this properly.
>
> Nobody cares, it seems. As you can imagine, I stopped to care enough after
> being switched to other projects.
I only care about it because I have the intention to get all 'randconfig'
kernels to build eventually. For stuff that is definitely 'legacy'
and won't get cleaned up properly, I'm fine with a hack.
> > Both the OHCI and MUSB drivers use exactly one register (CFGCHIP2)
>
> The idea at the time was to just ioremap() this register but I was not
> very eager.
Yes, that would work, too. However, that would cause problems later
if we ever try to make the davinci platform "multiplatform", unless we also
pass the physical address in a platform resource and make this a larger
driver. I think we can reasonably have an exported set of functions
declared in the platform data header file for these drivers, but passing
the physical address through a header file wouldn't be much of an improvement
over passing the virtual address.
> There was no USB PHY driver subsystem yet.
>
> > to control the clock, phy
>
> Note that it only controls PHY clock (PLL) which could be covered by an
> USB PHY driver.
Good point.
> > and host/gadget mode switch.
>
> The main mode the USB 2.0 PHY should function now is OTG. The host/gadged
> modes are forced overrides of the ID pin. Unfortunately, the board code has to
> force host mode when host-only driver config is selected (these MUSB's
> host/gadget only modes were removed at one point but got reintroduced again).
I think they are also required for 'randconfig' builds to some degree, because
you can build a kernel without host mode for instance.
> > In the modern world, we'd probably want to have a clock driver and
>
> Not sure about the clock driver...
>
> > a phy driver for these,
>
> Yes, that's what the MUSB maintainer wants too. The issue is the driver
> should somehow differ which USB controller it's bound too and do different
> things depending on that (at least that's how it looks now). I'm not sure it's
> possible, so probably should be rethought.
Yes, a phy driver seems the right approach if we can find someone to do it.
Ideally that should let us use generic versions of the ohci and musb drivers
even, if that's the only davinci specific part of these drivers.
> > based on a syscon driver.
>
> I don't know what syscon is...
The syscon (system controller) framework helps share a set of registers
across multiple drivers. If all accesses to the CFGCHIP2 register are
in a single PHY driver, we wouldn't need it.
> > In all honesty I don't see that happening on davinci.
>
> I don't think people use USB 1.1 controllers these days, especially when
> there is USB 2.0 in the same SoC. For MUSB, there were recent attempt to get
> the DA8xx driver out of the broken state but it was turned down as well, IIRC,
> since it didn't offer a PHY driver.
For USB 2.0 compliance you actually need to provide something to handle the
low speed modes. A lot of people use a hub to do that nowadays rather than
an OHCI or UHCI, but I don't know if that works with OTG.
Arnd
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base
2014-03-20 6:42 ` Arnd Bergmann
@ 2014-03-20 9:36 ` Sekhar Nori
2014-03-20 11:50 ` Arnd Bergmann
2014-03-20 16:20 ` Sergei Shtylyov
1 sibling, 1 reply; 205+ messages in thread
From: Sekhar Nori @ 2014-03-20 9:36 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 20 March 2014 12:12 PM, Arnd Bergmann wrote:
> On Thursday 20 March 2014 01:36:13 Sergei Shtylyov wrote:
>> On 03/19/2014 11:21 PM, Arnd Bergmann wrote:
>>> The question is whether there is anyone who would do this properly.
>>
>> Nobody cares, it seems. As you can imagine, I stopped to care enough after
>> being switched to other projects.
>
> I only care about it because I have the intention to get all 'randconfig'
> kernels to build eventually. For stuff that is definitely 'legacy'
> and won't get cleaned up properly, I'm fine with a hack.
>
>>> Both the OHCI and MUSB drivers use exactly one register (CFGCHIP2)
>>
>> The idea at the time was to just ioremap() this register but I was not
>> very eager.
>
> Yes, that would work, too. However, that would cause problems later
> if we ever try to make the davinci platform "multiplatform", unless we also
> pass the physical address in a platform resource and make this a larger
Some SATA driver work done by Bartlomiej Zolnierkiewicz needed driver
access to syscfg registers too and I just asked him to pass the physical
addresses using platform resource. I think thats the best bet we have in
the absence of a modern interface.
> The syscon (system controller) framework helps share a set of registers
> across multiple drivers. If all accesses to the CFGCHIP2 register are
> in a single PHY driver, we wouldn't need it.
CFGCHIP2 has controls both for USB 1.1 (OHCI) and USB 2.0 (MUSB). Not
sure if there can be a single PHY driver for both.
Thanks,
Sekhar
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base
2014-03-20 9:36 ` Sekhar Nori
@ 2014-03-20 11:50 ` Arnd Bergmann
2014-03-20 18:59 ` Sergei Shtylyov
0 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-20 11:50 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 20 March 2014, Sekhar Nori wrote:
> On Thursday 20 March 2014 12:12 PM, Arnd Bergmann wrote:
> > On Thursday 20 March 2014 01:36:13 Sergei Shtylyov wrote:
> >> On 03/19/2014 11:21 PM, Arnd Bergmann wrote:
> >>> The question is whether there is anyone who would do this properly.
> >>
> >> Nobody cares, it seems. As you can imagine, I stopped to care enough after
> >> being switched to other projects.
> >
> > I only care about it because I have the intention to get all 'randconfig'
> > kernels to build eventually. For stuff that is definitely 'legacy'
> > and won't get cleaned up properly, I'm fine with a hack.
> >
> >>> Both the OHCI and MUSB drivers use exactly one register (CFGCHIP2)
> >>
> >> The idea at the time was to just ioremap() this register but I was not
> >> very eager.
> >
> > Yes, that would work, too. However, that would cause problems later
> > if we ever try to make the davinci platform "multiplatform", unless we also
> > pass the physical address in a platform resource and make this a larger
>
> Some SATA driver work done by Bartlomiej Zolnierkiewicz needed driver
> access to syscfg registers too and I just asked him to pass the physical
> addresses using platform resource. I think thats the best bet we have in
> the absence of a modern interface.
Ok.
> > The syscon (system controller) framework helps share a set of registers
> > across multiple drivers. If all accesses to the CFGCHIP2 register are
> > in a single PHY driver, we wouldn't need it.
>
> CFGCHIP2 has controls both for USB 1.1 (OHCI) and USB 2.0 (MUSB). Not
> sure if there can be a single PHY driver for both.
The phy infrastructure explicitly supports multiple consumers for one
phy, if I'm reading the code correctly.
Arnd
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base
2014-03-20 11:50 ` Arnd Bergmann
@ 2014-03-20 18:59 ` Sergei Shtylyov
2014-03-20 18:22 ` Arnd Bergmann
0 siblings, 1 reply; 205+ messages in thread
From: Sergei Shtylyov @ 2014-03-20 18:59 UTC (permalink / raw)
To: linux-arm-kernel
Hello.
On 03/20/2014 02:50 PM, Arnd Bergmann wrote:
>>>>> The question is whether there is anyone who would do this properly.
>>>> Nobody cares, it seems. As you can imagine, I stopped to care enough after
>>>> being switched to other projects.
>>> I only care about it because I have the intention to get all 'randconfig'
>>> kernels to build eventually. For stuff that is definitely 'legacy'
>>> and won't get cleaned up properly, I'm fine with a hack.
>>>>> Both the OHCI and MUSB drivers use exactly one register (CFGCHIP2)
>>>> The idea at the time was to just ioremap() this register but I was not
>>>> very eager.
>>> Yes, that would work, too. However, that would cause problems later
>>> if we ever try to make the davinci platform "multiplatform", unless we also
>>> pass the physical address in a platform resource and make this a larger
>> Some SATA driver work done by Bartlomiej Zolnierkiewicz needed driver
>> access to syscfg registers too and I just asked him to pass the physical
>> addresses using platform resource. I think thats the best bet we have in
>> the absence of a modern interface.
> Ok.
Depends on what SYSCFG register it uses. It wouldn't be good if that
register range includes CFGCHIP2.
>>> The syscon (system controller) framework helps share a set of registers
>>> across multiple drivers. If all accesses to the CFGCHIP2 register are
>>> in a single PHY driver, we wouldn't need it.
>> CFGCHIP2 has controls both for USB 1.1 (OHCI) and USB 2.0 (MUSB). Not
>> sure if there can be a single PHY driver for both.
> The phy infrastructure explicitly supports multiple consumers for one
> phy, if I'm reading the code correctly.
Yes, it does. The issue is that the PHY code is different in MUSB and OHCI
drivers. I don't think the PHY driver knows what device binds to it.
> Arnd
WBR, Sergei
^ permalink raw reply [flat|nested] 205+ messages in thread* [PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base
2014-03-20 18:59 ` Sergei Shtylyov
@ 2014-03-20 18:22 ` Arnd Bergmann
2014-03-20 19:34 ` Sergei Shtylyov
0 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-20 18:22 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 20 March 2014 21:59:29 Sergei Shtylyov wrote:
>
> Yes, it does. The issue is that the PHY code is different in MUSB and OHCI
> drivers. I don't think the PHY driver knows what device binds to it.
At least in the DT case, it can get that information from DT, when you
set #phy-cells=<1>. I don't know how it would be done for platform_data,
but I assume one could find a way too.
Arnd
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base
2014-03-20 18:22 ` Arnd Bergmann
@ 2014-03-20 19:34 ` Sergei Shtylyov
0 siblings, 0 replies; 205+ messages in thread
From: Sergei Shtylyov @ 2014-03-20 19:34 UTC (permalink / raw)
To: linux-arm-kernel
Hello.
On 03/20/2014 09:22 PM, Arnd Bergmann wrote:
>> Yes, it does. The issue is that the PHY code is different in MUSB and OHCI
>> drivers. I don't think the PHY driver knows what device binds to it.
> At least in the DT case, it can get that information from DT, when you
> set #phy-cells=<1>. I don't know how it would be done for platform_data,
> but I assume one could find a way too.
#phy-cells is only defined for drivers/phy/ bindings IIRC, and I was
thinking a drivers/usb/phy/ driver so far. Probably you have a point and we
should go for the generic PHY framework instead. I'm just not very familiar
with it...
> Arnd
WBR, Sergei
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base
2014-03-20 6:42 ` Arnd Bergmann
2014-03-20 9:36 ` Sekhar Nori
@ 2014-03-20 16:20 ` Sergei Shtylyov
2014-03-20 19:42 ` Sergei Shtylyov
1 sibling, 1 reply; 205+ messages in thread
From: Sergei Shtylyov @ 2014-03-20 16:20 UTC (permalink / raw)
To: linux-arm-kernel
Hello.
On 20-03-2014 10:42, Arnd Bergmann wrote:
>>> Both the OHCI and MUSB drivers use exactly one register (CFGCHIP2)
>> The idea at the time was to just ioremap() this register but I was not
>> very eager.
... also it was suggested to pass the CFGCHIP2 address as a resource. I
certainly wasn't eager to do that since if done for both MUSB and OHCI, it
would cause sort of a resource conflict (platform device resources are
automatically registered in the resource tree, although without marking them
exclusive), even if we don't call request_mem_region() on them (we can't do
that since in this case the resource would be registered as exclusive, and the
second call would fail).
> Yes, that would work, too. However, that would cause problems later
> if we ever try to make the davinci platform "multiplatform", unless we also
> pass the physical address in a platform resource and make this a larger
> driver.
In my opinion, we don't have to pass CFGCHIP2 as a resource and could just
ioremap() the raw physical address.
> I think we can reasonably have an exported set of functions
> declared in the platform data header file for these drivers, but passing
> the physical address through a header file
That's how it's passed today (however, thru <mach/da8xx.h>).
> wouldn't be much of an improvement
> over passing the virtual address.
Not sure I understood about passing virtual address.
>> There was no USB PHY driver subsystem yet.
>>> to control the clock, phy
>> Note that it only controls PHY clock (PLL) which could be covered by an
>> USB PHY driver.
> Good point.
>>> and host/gadget mode switch.
>> The main mode the USB 2.0 PHY should function now is OTG. The host/gadged
>> modes are forced overrides of the ID pin. Unfortunately, the board code has to
>> force host mode when host-only driver config is selected (these MUSB's
>> host/gadget only modes were removed at one point but got reintroduced again).
> I think they are also required for 'randconfig' builds to some degree, because
> you can build a kernel without host mode for instance.
Yes.
>>> In the modern world, we'd probably want to have a clock driver and
>> Not sure about the clock driver...
>>> a phy driver for these,
>> Yes, that's what the MUSB maintainer wants too. The issue is the driver
>> should somehow differ which USB controller it's bound too and do different
>> things depending on that (at least that's how it looks now). I'm not sure it's
>> possible, so probably should be rethought.
> Yes, a phy driver seems the right approach if we can find someone to do it.
Perhaps a person that tried to unbreak the DA8xx MUSB driver could be
interested (and competent) enough to do it...
> Ideally that should let us use generic versions of the ohci and musb drivers
> even, if that's the only davinci specific part of these drivers.
No, not really. MUSB ceratinly has DaVinci specific register set mapped in
its register space. OHCI has up to 2 clocks to enable since USB 1.1 PHY can be
clocked from USB 2.0 PHY clock.
>>> based on a syscon driver.
>> I don't know what syscon is...
> The syscon (system controller) framework helps share a set of registers
> across multiple drivers. If all accesses to the CFGCHIP2 register are
> in a single PHY driver, we wouldn't need it.
Where can I find it in the kernel tree?
>>> In all honesty I don't see that happening on davinci.
>> I don't think people use USB 1.1 controllers these days, especially when
>> there is USB 2.0 in the same SoC. For MUSB, there were recent attempt to get
>> the DA8xx driver out of the broken state but it was turned down as well, IIRC,
>> since it didn't offer a PHY driver.
> For USB 2.0 compliance you actually need to provide something to handle the
> low speed modes. A lot of people use a hub to do that nowadays rather than
> an OHCI or UHCI, but I don't know if that works with OTG.
MUSB handles all speeds. I think the reason TI also included USB 1.1
controller lies in the somewhat dubious reputation of both MUSB hardware and
the Linux driver.
> Arnd
WBR, Sergei
^ permalink raw reply [flat|nested] 205+ messages in thread* [PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base
2014-03-20 16:20 ` Sergei Shtylyov
@ 2014-03-20 19:42 ` Sergei Shtylyov
0 siblings, 0 replies; 205+ messages in thread
From: Sergei Shtylyov @ 2014-03-20 19:42 UTC (permalink / raw)
To: linux-arm-kernel
On 03/20/2014 07:20 PM, Sergei Shtylyov wrote:
>> The syscon (system controller) framework helps share a set of registers
>> across multiple drivers. If all accesses to the CFGCHIP2 register are
>> in a single PHY driver, we wouldn't need it.
> Where can I find it in the kernel tree?
Found it.
WBR, Sergei
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base
2014-03-19 20:21 ` Arnd Bergmann
2014-03-19 22:36 ` Sergei Shtylyov
@ 2014-03-20 9:24 ` Sekhar Nori
2014-03-20 11:57 ` Arnd Bergmann
1 sibling, 1 reply; 205+ messages in thread
From: Sekhar Nori @ 2014-03-20 9:24 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd,
On Thursday 20 March 2014 01:51 AM, Arnd Bergmann wrote:
> On Wednesday 19 March 2014 23:53:18 Sergei Shtylyov wrote:
>> On 03/19/2014 10:29 PM, Arnd Bergmann wrote:
>>
>>> The ohci-da8xx driver uses the DA8XX_SYSCFG0_VIRT macro to
>>> access the CFGCHIP2 register for controlling its PHY.
>>
>>> The macro in turn relies on the da8xx_syscfg0_base global
>>> variable. Since the OHCI driver can be a loadable module,
>>> this requires the symbol to be exported from platform code.
>>
>>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>>> Cc: Sekhar Nori <nsekhar@ti.com>
>>> Cc: Kevin Hilman <khilman@deeprootsystems.com>
>>> Cc: davinci-linux-open-source at linux.davincidsp.com
>>> ---
>>> arch/arm/mach-davinci/devices-da8xx.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>
>>> diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
>>> index 0486cdf..4da868a 100644
>>> --- a/arch/arm/mach-davinci/devices-da8xx.c
>>> +++ b/arch/arm/mach-davinci/devices-da8xx.c
>>> @@ -66,6 +66,7 @@
>>> #define DA850_DMA_MMCSD1_TX EDMA_CTLR_CHAN(1, 29)
>>>
>>> void __iomem *da8xx_syscfg0_base;
>>> +EXPORT_SYMBOL_GPL(da8xx_syscfg0_base); /* used by OHCI_HCD */
>>
>> I have submitted such patch years ago and it was turned down.
>>
>
> The question is whether there is anyone who would do this properly.
>
> Both the OHCI and MUSB drivers use exactly one register (CFGCHIP2)
> to control the clock, phy and host/gadget mode switch.
>
> In the modern world, we'd probably want to have a clock driver and
> a phy driver for these, based on a syscon driver.
>
> In all honesty I don't see that happening on davinci.
>
> A somewhat better approach would be to export a set of exported
> functions to access the one register from the platform, e.g.
>
> u32 da8xx_cfgchip2_get(void);
> void da8xx_cfgchip2_set(u32);
>
> That interface would still be a bit ugly, but much better than
> what we have today, and easy to implement.
There is another thing we can do albeit in the driver (see patch).
Not sure how the USB maintainer will feel about it but I think this
has the advantage of not creating any hacky interfaces. And it
leaves me with the hope that someone will find the time to convert
to phy driver based on syscon at some point.
Thanks,
Sekhar
---8<---
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 3586460..c807d3f 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1178,7 +1178,8 @@ MODULE_LICENSE ("GPL");
#define SA1111_DRIVER ohci_hcd_sa1111_driver
#endif
-#ifdef CONFIG_ARCH_DAVINCI_DA8XX
+/* DA8XX uses platform internal symbols. Cannot be built as module. */
+#if defined(CONFIG_ARCH_DAVINCI_DA8XX) && !defined(CONFIG_USB_OHCI_HCD_MODULE)
#include "ohci-da8xx.c"
#define DAVINCI_PLATFORM_DRIVER ohci_hcd_da8xx_driver
#endif
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base
2014-03-20 9:24 ` Sekhar Nori
@ 2014-03-20 11:57 ` Arnd Bergmann
2014-03-20 12:22 ` Sekhar Nori
0 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-20 11:57 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 20 March 2014, Sekhar Nori wrote:
> There is another thing we can do albeit in the driver (see patch).
> Not sure how the USB maintainer will feel about it but I think this
> has the advantage of not creating any hacky interfaces. And it
> leaves me with the hope that someone will find the time to convert
> to phy driver based on syscon at some point.
Interesting hack.
> diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
> index 3586460..c807d3f 100644
> --- a/drivers/usb/host/ohci-hcd.c
> +++ b/drivers/usb/host/ohci-hcd.c
> @@ -1178,7 +1178,8 @@ MODULE_LICENSE ("GPL");
> #define SA1111_DRIVER ohci_hcd_sa1111_driver
> #endif
>
> -#ifdef CONFIG_ARCH_DAVINCI_DA8XX
> +/* DA8XX uses platform internal symbols. Cannot be built as module. */
> +#if defined(CONFIG_ARCH_DAVINCI_DA8XX) && !defined(CONFIG_USB_OHCI_HCD_MODULE)
> #include "ohci-da8xx.c"
> #define DAVINCI_PLATFORM_DRIVER ohci_hcd_da8xx_driver
> #endif
I wouldn't want to submit that patch to GregKH ;-)
How about doing the same thing in a somewhat less sneaky way?
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 0fe936c..857250a 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -417,6 +417,16 @@ config USB_OHCI_HCD_OMAP3
Enables support for the on-chip OHCI controller on
OMAP3 and later chips.
+config USB_OHCI_HCD_DAVINCI
+ bool "OHCI support for TI DaVinci DA8xx"
+ depends on ARCH_DAVINCI_DA8XX
+ depends on USB_OHCI_HCD=y
+ default y
+ help
+ Enables support for the DaVinci DA8xx integrated OHCI
+ controller. This driver cannot currently be a loadable
+ module because it lacks a proper PHY abstraction.
+
config USB_OHCI_ATH79
bool "USB OHCI support for the Atheros AR71XX/AR7240 SoCs (DEPRECATED)"
depends on (SOC_AR71XX || SOC_AR724X)
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 3586460..f98d03f 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1178,7 +1178,7 @@ MODULE_LICENSE ("GPL");
#define SA1111_DRIVER ohci_hcd_sa1111_driver
#endif
-#ifdef CONFIG_ARCH_DAVINCI_DA8XX
+#ifdef CONFIG_USB_OHCI_HCD_DAVINCI
#include "ohci-da8xx.c"
#define DAVINCI_PLATFORM_DRIVER ohci_hcd_da8xx_driver
#endif
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base
2014-03-20 11:57 ` Arnd Bergmann
@ 2014-03-20 12:22 ` Sekhar Nori
0 siblings, 0 replies; 205+ messages in thread
From: Sekhar Nori @ 2014-03-20 12:22 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 20 March 2014 05:27 PM, Arnd Bergmann wrote:
> On Thursday 20 March 2014, Sekhar Nori wrote:
>> diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
>> index 3586460..c807d3f 100644
>> --- a/drivers/usb/host/ohci-hcd.c
>> +++ b/drivers/usb/host/ohci-hcd.c
>> @@ -1178,7 +1178,8 @@ MODULE_LICENSE ("GPL");
>> #define SA1111_DRIVER ohci_hcd_sa1111_driver
>> #endif
>>
>> -#ifdef CONFIG_ARCH_DAVINCI_DA8XX
>> +/* DA8XX uses platform internal symbols. Cannot be built as module. */
>> +#if defined(CONFIG_ARCH_DAVINCI_DA8XX) && !defined(CONFIG_USB_OHCI_HCD_MODULE)
>> #include "ohci-da8xx.c"
>> #define DAVINCI_PLATFORM_DRIVER ohci_hcd_da8xx_driver
>> #endif
>
> I wouldn't want to submit that patch to GregKH ;-)
>
> How about doing the same thing in a somewhat less sneaky way?
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Much better! Please feel free to add
Acked-by: Sekhar Nori <nsekhar@ti.com>
if it helps.
Regards,
Sekhar
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 07/62] ARM: davinci: make dm644x-evm phy fixup conditional
2014-03-19 19:28 ` Arnd Bergmann
` (6 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-20 12:29 ` Sekhar Nori
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
We cannot call phy_register_fixup_for_uid() if CONFIG_PHYLIB
is not built into the kernel, and we should not enforce that
to be built into vmlinux either, because one might want to
disable the entire network stack.
This change uses a compile-time condition on CONFIG_PHYLIB
to remove the call in the cases where it cannot work.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: davinci-linux-open-source at linux.davincidsp.com
---
arch/arm/mach-davinci/board-dm644x-evm.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
index 5602957..e583e58 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -804,11 +804,12 @@ static __init void davinci_evm_init(void)
/* irlml6401 switches over 1A, in under 8 msec */
davinci_setup_usb(1000, 8);
- soc_info->emac_pdata->phy_id = DM644X_EVM_PHY_ID;
- /* Register the fixup for PHY on DaVinci */
- phy_register_fixup_for_uid(LXT971_PHY_ID, LXT971_PHY_MASK,
- davinci_phy_fixup);
-
+ if (IS_BUILTIN(CONFIG_PHYLIB)) {
+ soc_info->emac_pdata->phy_id = DM644X_EVM_PHY_ID;
+ /* Register the fixup for PHY on DaVinci */
+ phy_register_fixup_for_uid(LXT971_PHY_ID, LXT971_PHY_MASK,
+ davinci_phy_fixup);
+ }
}
MACHINE_START(DAVINCI_EVM, "DaVinci DM644x EVM")
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 07/62] ARM: davinci: make dm644x-evm phy fixup conditional
2014-03-19 19:29 ` [PATCH 07/62] ARM: davinci: make dm644x-evm phy fixup conditional Arnd Bergmann
@ 2014-03-20 12:29 ` Sekhar Nori
0 siblings, 0 replies; 205+ messages in thread
From: Sekhar Nori @ 2014-03-20 12:29 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 20 March 2014 12:59 AM, Arnd Bergmann wrote:
> We cannot call phy_register_fixup_for_uid() if CONFIG_PHYLIB
> is not built into the kernel, and we should not enforce that
> to be built into vmlinux either, because one might want to
> disable the entire network stack.
>
> This change uses a compile-time condition on CONFIG_PHYLIB
> to remove the call in the cases where it cannot work.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Sekhar Nori <nsekhar@ti.com>
> Cc: Kevin Hilman <khilman@deeprootsystems.com>
> Cc: davinci-linux-open-source at linux.davincidsp.com
Acked-by: Sekhar Nori <nsekhar@ti.com>
Thanks,
Sekhar
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 08/62] ARM: davinci: use explicit 'select' for DA850_EVM
2014-03-19 19:28 ` Arnd Bergmann
` (7 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-20 12:47 ` Sekhar Nori
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
The DAVINCI_DA850_EVM board uses an unusual method to
enable the GPIO_PCA953X and KEYBOARD_GPIO_POLLED symbols,
which leads to the dependencies on these symbols being
ignored. As GPIO_PCA953X actually requires I2C, that
can lead to build failures when I2C is disabled.
This patch removes the duplicate symbol definitions
and instead adds equivalent 'select' statements that
are conditional on the underlying dependencies.
A different question whether we actually want to automatically
enable them at all or rather put them into defconfig,
but that should be a separate patch.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: davinci-linux-open-source at linux.davincidsp.com
---
arch/arm/mach-davinci/Kconfig | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index 3b98e34..df794e9 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -163,6 +163,8 @@ config MACH_DAVINCI_DA850_EVM
bool "TI DA850/OMAP-L138/AM18x Reference Platform"
default ARCH_DAVINCI_DA850
depends on ARCH_DAVINCI_DA850
+ select GPIO_PCA953X if I2C
+ select KEYBOARD_GPIO_POLLED if GPIOLIB
help
Say Y here to select the TI DA850/OMAP-L138/AM18x Evaluation Module.
@@ -209,11 +211,6 @@ config DA850_WL12XX
Say Y if you want to use a wl1271 expansion card connected to the
AM18x EVM.
-config GPIO_PCA953X
- default MACH_DAVINCI_DA850_EVM
-
-config KEYBOARD_GPIO_POLLED
- default MACH_DAVINCI_DA850_EVM
config MACH_MITYOMAPL138
bool "Critical Link MityDSP-L138/MityARM-1808 SoM"
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 08/62] ARM: davinci: use explicit 'select' for DA850_EVM
2014-03-19 19:29 ` [PATCH 08/62] ARM: davinci: use explicit 'select' for DA850_EVM Arnd Bergmann
@ 2014-03-20 12:47 ` Sekhar Nori
2014-03-21 15:56 ` Arnd Bergmann
0 siblings, 1 reply; 205+ messages in thread
From: Sekhar Nori @ 2014-03-20 12:47 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 20 March 2014 12:59 AM, Arnd Bergmann wrote:
> The DAVINCI_DA850_EVM board uses an unusual method to
> enable the GPIO_PCA953X and KEYBOARD_GPIO_POLLED symbols,
> which leads to the dependencies on these symbols being
> ignored. As GPIO_PCA953X actually requires I2C, that
> can lead to build failures when I2C is disabled.
>
> This patch removes the duplicate symbol definitions
I am okay with this..
> and instead adds equivalent 'select' statements that
> are conditional on the underlying dependencies.
.. but not sure this is needed. The PCA953X was defaulted to y mainly
because the IO expander was used to detect presence of daughter cards.
Even then, I don't think there is any need to force its selection.
>
> A different question whether we actually want to automatically
> enable them at all or rather put them into defconfig,
> but that should be a separate patch.
It can be enabled through defconfig as you said. I agree that can be a
separate patch. For now, just dropping the replicated Kconfig symbols
should be okay.
Thanks,
Sekhar
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 08/62] ARM: davinci: use explicit 'select' for DA850_EVM
2014-03-20 12:47 ` Sekhar Nori
@ 2014-03-21 15:56 ` Arnd Bergmann
2014-03-24 5:09 ` Sekhar Nori
0 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-21 15:56 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 20 March 2014, Sekhar Nori wrote:
> On Thursday 20 March 2014 12:59 AM, Arnd Bergmann wrote:
> > The DAVINCI_DA850_EVM board uses an unusual method to
> > enable the GPIO_PCA953X and KEYBOARD_GPIO_POLLED symbols,
> > which leads to the dependencies on these symbols being
> > ignored. As GPIO_PCA953X actually requires I2C, that
> > can lead to build failures when I2C is disabled.
> >
> > This patch removes the duplicate symbol definitions
>
> I am okay with this..
>
> > and instead adds equivalent 'select' statements that
> > are conditional on the underlying dependencies.
>
> .. but not sure this is needed. The PCA953X was defaulted to y mainly
> because the IO expander was used to detect presence of daughter cards.
> Even then, I don't think there is any need to force its selection.
>
> >
> > A different question whether we actually want to automatically
> > enable them at all or rather put them into defconfig,
> > but that should be a separate patch.
>
> It can be enabled through defconfig as you said. I agree that can be a
> separate patch. For now, just dropping the replicated Kconfig symbols
> should be okay.
Ok, even better then. I was trying to change the behavior as little
as possible, but not selecting the drivers is certainly the correct
approach. I've put the two symbols into the defconfig now so the builds
are unchanged.
Arnd
8<----
>From 5eaf7fdfe7c831d3aa24428a6e8d4509ac160db6 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Tue, 18 Feb 2014 12:23:19 +0100
Subject: [PATCH] ARM: davinci: use explicit 'select' for DA850_EVM
The DAVINCI_DA850_EVM board uses an unusual method to
enable the GPIO_PCA953X and KEYBOARD_GPIO_POLLED symbols,
which leads to the dependencies on these symbols being
ignored. As GPIO_PCA953X actually requires I2C, that
can lead to build failures when I2C is disabled.
This patch removes the duplicate symbol definitions
and instead enables them from the davinci_all_defconfig
file.
A different question whether we actually want to automatically
enable them at all or rather put them into defconfig,
but that should be a separate patch.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Sekhar Nori <nsekhar@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: davinci-linux-open-source at linux.davincidsp.com
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index fff4eb6..16bdfab 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -218,3 +218,5 @@ CONFIG_DEBUG_ERRORS=y
# CONFIG_CRYPTO_ANSI_CPRNG is not set
# CONFIG_CRYPTO_HW is not set
CONFIG_CRC_T10DIF=m
+CONFIG_GPIO_PCA953X=y
+CONFIG_KEYBOARD_GPIO_POLLED=y
diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index 3b98e34..db18ef8 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -209,11 +209,6 @@ config DA850_WL12XX
Say Y if you want to use a wl1271 expansion card connected to the
AM18x EVM.
-config GPIO_PCA953X
- default MACH_DAVINCI_DA850_EVM
-
-config KEYBOARD_GPIO_POLLED
- default MACH_DAVINCI_DA850_EVM
config MACH_MITYOMAPL138
bool "Critical Link MityDSP-L138/MityARM-1808 SoM"
^ permalink raw reply related [flat|nested] 205+ messages in thread
* [PATCH 08/62] ARM: davinci: use explicit 'select' for DA850_EVM
2014-03-21 15:56 ` Arnd Bergmann
@ 2014-03-24 5:09 ` Sekhar Nori
0 siblings, 0 replies; 205+ messages in thread
From: Sekhar Nori @ 2014-03-24 5:09 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 21 March 2014 09:26 PM, Arnd Bergmann wrote:
> From 5eaf7fdfe7c831d3aa24428a6e8d4509ac160db6 Mon Sep 17 00:00:00 2001
> From: Arnd Bergmann <arnd@arndb.de>
> Date: Tue, 18 Feb 2014 12:23:19 +0100
> Subject: [PATCH] ARM: davinci: use explicit 'select' for DA850_EVM
>
> The DAVINCI_DA850_EVM board uses an unusual method to
> enable the GPIO_PCA953X and KEYBOARD_GPIO_POLLED symbols,
> which leads to the dependencies on these symbols being
> ignored. As GPIO_PCA953X actually requires I2C, that
> can lead to build failures when I2C is disabled.
>
> This patch removes the duplicate symbol definitions
> and instead enables them from the davinci_all_defconfig
> file.
> A different question whether we actually want to automatically
> enable them at all or rather put them into defconfig,
> but that should be a separate patch.
This para can be dropped now.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Acked-by: Sekhar Nori <nsekhar@ti.com>
> Cc: Kevin Hilman <khilman@deeprootsystems.com>
> Cc: davinci-linux-open-source at linux.davincidsp.com
Acked-by: Sekhar Nori <nsekhar@ti.com>
Thanks,
Sekhar
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 09/62] ARM: efm32: allow uncompress debug output
2014-03-19 19:28 ` Arnd Bergmann
` (8 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-20 20:51 ` Uwe Kleine-König
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
efm32 has no mach/uncompress.h, but we can trivially use
the fallback to the ll_debug code by just allowing this
option in Kconfig.
Found during randconfig testing.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Uwe Kleine-K?nig <kernel@pengutronix.de>
---
arch/arm/Kconfig.debug | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index dbb6f15..8983919 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -1158,7 +1158,7 @@ config DEBUG_UNCOMPRESS
config UNCOMPRESS_INCLUDE
string
default "debug/uncompress.h" if ARCH_MULTIPLATFORM || ARCH_MSM || \
- ARCH_EXYNOS
+ ARCH_EXYNOS || ARCH_EFM32
default "mach/uncompress.h"
config EARLY_PRINTK
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 09/62] ARM: efm32: allow uncompress debug output
2014-03-19 19:29 ` [PATCH 09/62] ARM: efm32: allow uncompress debug output Arnd Bergmann
@ 2014-03-20 20:51 ` Uwe Kleine-König
0 siblings, 0 replies; 205+ messages in thread
From: Uwe Kleine-König @ 2014-03-20 20:51 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Mar 19, 2014 at 08:29:06PM +0100, Arnd Bergmann wrote:
> efm32 has no mach/uncompress.h, but we can trivially use
> the fallback to the ll_debug code by just allowing this
> option in Kconfig.
>
> Found during randconfig testing.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Uwe Kleine-K?nig <kernel@pengutronix.de>
I didn't test it (and in fact I cannot because there is too little RAM
to run a zImage on my board[1]) but the change looks good for a board
having more RAM, so
Acked-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
[1] maybe it would run long enough to see some output, but meh
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 10/62] ARM: efm32: select AUTO_ZRELADDR
2014-03-19 19:28 ` Arnd Bergmann
` (9 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-20 20:48 ` Uwe Kleine-König
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
The efm32 platform does not provide a zreladdr-y line its Makefile.boot,
so we always have to use CONFIG_AUTO_ZRELADDR in order to successfully
build and link a zImage.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Uwe Kleine-K?nig <kernel@pengutronix.de>
---
arch/arm/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 62ede9b..5776c12 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -422,6 +422,7 @@ config ARCH_EFM32
bool "Energy Micro efm32"
depends on !MMU
select ARCH_REQUIRE_GPIOLIB
+ select AUTO_ZRELADDR
select ARM_NVIC
select CLKSRC_OF
select COMMON_CLK
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 10/62] ARM: efm32: select AUTO_ZRELADDR
2014-03-19 19:29 ` [PATCH 10/62] ARM: efm32: select AUTO_ZRELADDR Arnd Bergmann
@ 2014-03-20 20:48 ` Uwe Kleine-König
2014-03-20 22:16 ` Arnd Bergmann
0 siblings, 1 reply; 205+ messages in thread
From: Uwe Kleine-König @ 2014-03-20 20:48 UTC (permalink / raw)
To: linux-arm-kernel
Hello Arnd,
On Wed, Mar 19, 2014 at 08:29:07PM +0100, Arnd Bergmann wrote:
> The efm32 platform does not provide a zreladdr-y line its Makefile.boot,
> so we always have to use CONFIG_AUTO_ZRELADDR in order to successfully
> build and link a zImage.
I wonder why you need to AUTO_ZRELADDR (which is there to guess
zreladdr) while efm32 doesn't have an MMU and so there is nothing to
guess. So I think this patch fixes a build problem, but it's not a good
change.
Best regards
Uwe
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Uwe Kleine-K?nig <kernel@pengutronix.de>
> ---
> arch/arm/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 62ede9b..5776c12 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -422,6 +422,7 @@ config ARCH_EFM32
> bool "Energy Micro efm32"
> depends on !MMU
> select ARCH_REQUIRE_GPIOLIB
> + select AUTO_ZRELADDR
> select ARM_NVIC
> select CLKSRC_OF
> select COMMON_CLK
> --
> 1.8.3.2
>
>
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 10/62] ARM: efm32: select AUTO_ZRELADDR
2014-03-20 20:48 ` Uwe Kleine-König
@ 2014-03-20 22:16 ` Arnd Bergmann
2014-03-21 14:32 ` Uwe Kleine-König
0 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-20 22:16 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 20 March 2014 21:48:47 Uwe Kleine-K?nig wrote:
>
> On Wed, Mar 19, 2014 at 08:29:07PM +0100, Arnd Bergmann wrote:
> > The efm32 platform does not provide a zreladdr-y line its Makefile.boot,
> > so we always have to use CONFIG_AUTO_ZRELADDR in order to successfully
> > build and link a zImage.
> I wonder why you need to AUTO_ZRELADDR (which is there to guess
> zreladdr) while efm32 doesn't have an MMU and so there is nothing to
> guess. So I think this patch fixes a build problem, but it's not a good
> change.
It is required in order to build a compressed zImage file. You mentioned
before that your system does not have enough RAM to support this, but
the compile-time option exists, and there is no dependency on MMU support
for it, nor should there be.
Arnd
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 10/62] ARM: efm32: select AUTO_ZRELADDR
2014-03-20 22:16 ` Arnd Bergmann
@ 2014-03-21 14:32 ` Uwe Kleine-König
2014-03-21 15:10 ` Arnd Bergmann
0 siblings, 1 reply; 205+ messages in thread
From: Uwe Kleine-König @ 2014-03-21 14:32 UTC (permalink / raw)
To: linux-arm-kernel
Hello Arnd,
On Thu, Mar 20, 2014 at 11:16:20PM +0100, Arnd Bergmann wrote:
> On Thursday 20 March 2014 21:48:47 Uwe Kleine-K?nig wrote:
> >
> > On Wed, Mar 19, 2014 at 08:29:07PM +0100, Arnd Bergmann wrote:
> > > The efm32 platform does not provide a zreladdr-y line its Makefile.boot,
> > > so we always have to use CONFIG_AUTO_ZRELADDR in order to successfully
> > > build and link a zImage.
> > I wonder why you need to AUTO_ZRELADDR (which is there to guess
> > zreladdr) while efm32 doesn't have an MMU and so there is nothing to
> > guess. So I think this patch fixes a build problem, but it's not a good
> > change.
>
> It is required in order to build a compressed zImage file. You mentioned
> before that your system does not have enough RAM to support this, but
> the compile-time option exists, and there is no dependency on MMU support
> for it, nor should there be.
My objection isn't about having only little RAM. AUTO_ZRELADDR is about
guessing the physical address corresponding to PAGE_OFFSET. But without
an MMU there is nothing to guess. So I wonder if the better change would
be to do:
#ifdef CONFIG_MMU
#ifdef CONFIG_AUTO_ZRELADDR
... guess zreladdress based on instruction pointer
#else
... use zreladdr from Makefile.boot
#endif
#else
... use zreladdr = PAGE_OFFSET
#endif
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 10/62] ARM: efm32: select AUTO_ZRELADDR
2014-03-21 14:32 ` Uwe Kleine-König
@ 2014-03-21 15:10 ` Arnd Bergmann
2014-03-21 18:54 ` Uwe Kleine-König
0 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-21 15:10 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 21 March 2014 15:32:24 Uwe Kleine-K?nig wrote:
> On Thu, Mar 20, 2014 at 11:16:20PM +0100, Arnd Bergmann wrote:
> > On Thursday 20 March 2014 21:48:47 Uwe Kleine-K?nig wrote:
> > >
> > > On Wed, Mar 19, 2014 at 08:29:07PM +0100, Arnd Bergmann wrote:
> > > > The efm32 platform does not provide a zreladdr-y line its Makefile.boot,
> > > > so we always have to use CONFIG_AUTO_ZRELADDR in order to successfully
> > > > build and link a zImage.
> > > I wonder why you need to AUTO_ZRELADDR (which is there to guess
> > > zreladdr) while efm32 doesn't have an MMU and so there is nothing to
> > > guess. So I think this patch fixes a build problem, but it's not a good
> > > change.
> >
> > It is required in order to build a compressed zImage file. You mentioned
> > before that your system does not have enough RAM to support this, but
> > the compile-time option exists, and there is no dependency on MMU support
> > for it, nor should there be.
> My objection isn't about having only little RAM. AUTO_ZRELADDR is about
> guessing the physical address corresponding to PAGE_OFFSET. But without
> an MMU there is nothing to guess. So I wonder if the better change would
> be to do:
>
> #ifdef CONFIG_MMU
> #ifdef CONFIG_AUTO_ZRELADDR
> ... guess zreladdress based on instruction pointer
> #else
> ... use zreladdr from Makefile.boot
> #endif
> #else
> ... use zreladdr = PAGE_OFFSET
> #endif
>
I don't see a reason to change the existing logic, it works for
both MMU and NOMMU kernels, and you are talking about *three* instructions
here.
Also, once we integrate efm32 into ARCH_MULTIPLATFORM, it AUTO_ZRELADDR
will be set anyway, unless we add another useless conditional.
Arnd
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 10/62] ARM: efm32: select AUTO_ZRELADDR
2014-03-21 15:10 ` Arnd Bergmann
@ 2014-03-21 18:54 ` Uwe Kleine-König
2014-03-21 21:34 ` Rob Herring
0 siblings, 1 reply; 205+ messages in thread
From: Uwe Kleine-König @ 2014-03-21 18:54 UTC (permalink / raw)
To: linux-arm-kernel
Hello Arnd,
On Fri, Mar 21, 2014 at 04:10:37PM +0100, Arnd Bergmann wrote:
> On Friday 21 March 2014 15:32:24 Uwe Kleine-K?nig wrote:
> > On Thu, Mar 20, 2014 at 11:16:20PM +0100, Arnd Bergmann wrote:
> > > On Thursday 20 March 2014 21:48:47 Uwe Kleine-K?nig wrote:
> > > >
> > > > On Wed, Mar 19, 2014 at 08:29:07PM +0100, Arnd Bergmann wrote:
> > > > > The efm32 platform does not provide a zreladdr-y line its Makefile.boot,
> > > > > so we always have to use CONFIG_AUTO_ZRELADDR in order to successfully
> > > > > build and link a zImage.
> > > > I wonder why you need to AUTO_ZRELADDR (which is there to guess
> > > > zreladdr) while efm32 doesn't have an MMU and so there is nothing to
> > > > guess. So I think this patch fixes a build problem, but it's not a good
> > > > change.
> > >
> > > It is required in order to build a compressed zImage file. You mentioned
> > > before that your system does not have enough RAM to support this, but
> > > the compile-time option exists, and there is no dependency on MMU support
> > > for it, nor should there be.
> > My objection isn't about having only little RAM. AUTO_ZRELADDR is about
> > guessing the physical address corresponding to PAGE_OFFSET. But without
> > an MMU there is nothing to guess. So I wonder if the better change would
> > be to do:
> >
> > #ifdef CONFIG_MMU
> > #ifdef CONFIG_AUTO_ZRELADDR
> > ... guess zreladdress based on instruction pointer
> > #else
> > ... use zreladdr from Makefile.boot
> > #endif
> > #else
> > ... use zreladdr = PAGE_OFFSET
> > #endif
> >
>
> I don't see a reason to change the existing logic, it works for
> both MMU and NOMMU kernels, and you are talking about *three* instructions
> here.
it doesn't matter how many instructions are involved. The relevant
difference is that with my approach you fix the problem for all no-MMU
platforms, with yours you only fix efm32. (OK, I think there are not too
many no-MMU platforms, but still.) An even easier implementation would
be to add something like:
ifeq($(zreladdr-y)$(CONFIG_MMU),)
zreladdr-y := CONFIG_PAGE_OFFSET + CONFIG_TEXT_OFFSET
endif
to arch/arm/boot/Makefile.
But I don't care much, if you still want to make EFM32 select
AUTO_ZRELADDR go ahead.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 10/62] ARM: efm32: select AUTO_ZRELADDR
2014-03-21 18:54 ` Uwe Kleine-König
@ 2014-03-21 21:34 ` Rob Herring
2014-03-22 9:27 ` Arnd Bergmann
0 siblings, 1 reply; 205+ messages in thread
From: Rob Herring @ 2014-03-21 21:34 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Mar 21, 2014 at 1:54 PM, Uwe Kleine-K?nig
<u.kleine-koenig@pengutronix.de> wrote:
> Hello Arnd,
>
> On Fri, Mar 21, 2014 at 04:10:37PM +0100, Arnd Bergmann wrote:
>> On Friday 21 March 2014 15:32:24 Uwe Kleine-K?nig wrote:
>> > On Thu, Mar 20, 2014 at 11:16:20PM +0100, Arnd Bergmann wrote:
>> > > On Thursday 20 March 2014 21:48:47 Uwe Kleine-K?nig wrote:
>> > > >
>> > > > On Wed, Mar 19, 2014 at 08:29:07PM +0100, Arnd Bergmann wrote:
>> > > > > The efm32 platform does not provide a zreladdr-y line its Makefile.boot,
>> > > > > so we always have to use CONFIG_AUTO_ZRELADDR in order to successfully
>> > > > > build and link a zImage.
>> > > > I wonder why you need to AUTO_ZRELADDR (which is there to guess
>> > > > zreladdr) while efm32 doesn't have an MMU and so there is nothing to
>> > > > guess. So I think this patch fixes a build problem, but it's not a good
>> > > > change.
>> > >
>> > > It is required in order to build a compressed zImage file. You mentioned
>> > > before that your system does not have enough RAM to support this, but
>> > > the compile-time option exists, and there is no dependency on MMU support
>> > > for it, nor should there be.
>> > My objection isn't about having only little RAM. AUTO_ZRELADDR is about
>> > guessing the physical address corresponding to PAGE_OFFSET. But without
>> > an MMU there is nothing to guess. So I wonder if the better change would
>> > be to do:
>> >
>> > #ifdef CONFIG_MMU
>> > #ifdef CONFIG_AUTO_ZRELADDR
>> > ... guess zreladdress based on instruction pointer
>> > #else
>> > ... use zreladdr from Makefile.boot
>> > #endif
>> > #else
>> > ... use zreladdr = PAGE_OFFSET
>> > #endif
>> >
>>
>> I don't see a reason to change the existing logic, it works for
>> both MMU and NOMMU kernels, and you are talking about *three* instructions
>> here.
> it doesn't matter how many instructions are involved. The relevant
> difference is that with my approach you fix the problem for all no-MMU
> platforms, with yours you only fix efm32. (OK, I think there are not too
> many no-MMU platforms, but still.) An even easier implementation would
> be to add something like:
>
> ifeq($(zreladdr-y)$(CONFIG_MMU),)
> zreladdr-y := CONFIG_PAGE_OFFSET + CONFIG_TEXT_OFFSET
> endif
>
> to arch/arm/boot/Makefile.
>
> But I don't care much, if you still want to make EFM32 select
> AUTO_ZRELADDR go ahead.
How about a kconfig fix:
bool "Auto calculation of the decompressed kernel image address" if MMU
default y if !MMU
Rob
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 10/62] ARM: efm32: select AUTO_ZRELADDR
2014-03-21 21:34 ` Rob Herring
@ 2014-03-22 9:27 ` Arnd Bergmann
2014-03-23 11:32 ` Uwe Kleine-König
0 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-22 9:27 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 21 March 2014, Rob Herring wrote:
> On Fri, Mar 21, 2014 at 1:54 PM, Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de> wrote:
> > On Fri, Mar 21, 2014 at 04:10:37PM +0100, Arnd Bergmann wrote:
> >> I don't see a reason to change the existing logic, it works for
> >> both MMU and NOMMU kernels, and you are talking about three instructions
> >> here.
> > it doesn't matter how many instructions are involved. The relevant
> > difference is that with my approach you fix the problem for all no-MMU
> > platforms, with yours you only fix efm32. (OK, I think there are not too
> > many no-MMU platforms, but still.) An even easier implementation would
> > be to add something like:
> >
> > ifeq($(zreladdr-y)$(CONFIG_MMU),)
> > zreladdr-y := CONFIG_PAGE_OFFSET + CONFIG_TEXT_OFFSET
> > endif
> >
> > to arch/arm/boot/Makefile.
This makes sense, we can add it as soon as we have a use for it. At the
moment, the only problem we have is a randconfig build error, and the
obvious change I proposed should work just fine.
> > But I don't care much, if you still want to make EFM32 select
> > AUTO_ZRELADDR go ahead.
>
> How about a kconfig fix:
>
> bool "Auto calculation of the decompressed kernel image address" if MMU
> default y if !MMU
This however would break builds that today for some reason cannot use
AUTO_ZRELADDR on !MMU kernels, i.e. has a funny bootloader that
uses ZBOOT_ROM or other tricks. In principle any platform should
work with MMU disabled (although I'm sure there are tons of bugs),
and not every one uses AUTO_ZRELADDR today. Uwe's suggestion above
takes advantage of the fact that !MMU-kernels know what physical
address they run on.
Arnd
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 10/62] ARM: efm32: select AUTO_ZRELADDR
2014-03-22 9:27 ` Arnd Bergmann
@ 2014-03-23 11:32 ` Uwe Kleine-König
2014-03-24 7:28 ` [PATCH] ARM: determine zreladdr for no-MMU machines automatically Uwe Kleine-König
0 siblings, 1 reply; 205+ messages in thread
From: Uwe Kleine-König @ 2014-03-23 11:32 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, Mar 22, 2014 at 10:27:09AM +0100, Arnd Bergmann wrote:
> On Friday 21 March 2014, Rob Herring wrote:
> > On Fri, Mar 21, 2014 at 1:54 PM, Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de> wrote:
> > > On Fri, Mar 21, 2014 at 04:10:37PM +0100, Arnd Bergmann wrote:
> > >> I don't see a reason to change the existing logic, it works for
> > >> both MMU and NOMMU kernels, and you are talking about three instructions
> > >> here.
> > > it doesn't matter how many instructions are involved. The relevant
> > > difference is that with my approach you fix the problem for all no-MMU
> > > platforms, with yours you only fix efm32. (OK, I think there are not too
> > > many no-MMU platforms, but still.) An even easier implementation would
> > > be to add something like:
> > >
> > > ifeq($(zreladdr-y)$(CONFIG_MMU),)
> > > zreladdr-y := CONFIG_PAGE_OFFSET + CONFIG_TEXT_OFFSET
> > > endif
> > >
> > > to arch/arm/boot/Makefile.
>
> This makes sense, we can add it as soon as we have a use for it. At the
> moment, the only problem we have is a randconfig build error, and the
> obvious change I proposed should work just fine.
My suggestion is an alternative fix for the randconfig error you see, so
there is a use already now. I fail to compile a zImage for different
reasons on top of next, but maybe this works instead of your patch:
diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
index ec2f8065f955..2d935dd098e5 100644
--- a/arch/arm/boot/Makefile
+++ b/arch/arm/boot/Makefile
@@ -15,6 +15,10 @@ ifneq ($(MACHINE),)
include $(srctree)/$(MACHINE)/Makefile.boot
endif
+ifeq ($(zreladdr-y)$(CONFIG_MMU),)
+zreladdr-y := $(CONFIG_PAGE_OFFSET)+$(TEXT_OFFSET)
+endif
+
# Note: the following conditions must always be true:
# ZRELADDR == virt_to_phys(PAGE_OFFSET + TEXT_OFFSET)
# PARAMS_PHYS must be within 4MB of ZRELADDR
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply related [flat|nested] 205+ messages in thread
* [PATCH] ARM: determine zreladdr for no-MMU machines automatically
2014-03-23 11:32 ` Uwe Kleine-König
@ 2014-03-24 7:28 ` Uwe Kleine-König
0 siblings, 0 replies; 205+ messages in thread
From: Uwe Kleine-König @ 2014-03-24 7:28 UTC (permalink / raw)
To: linux-arm-kernel
zreladdr must be virt_to_phys(PAGE_OFFSET + TEXT_OFFSET). For no-MMU
machines virt_to_phys is the identity mapping so zreladdr can be defined
to just PAGE_OFFSET + TEXT_OFFSET for no-MMU machines.
This fixes one of the problems when trying to compile a zImage for efm32
because this platform doesn't define zreladdr.
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
Hello,
I tested this patch on top of Arnd's randconfig branch[1], it allowed to
drop db5fbcd0d71e (ARM: efm32: select AUTO_ZRELADDR) from it with zImage
still being compilable. When checking at91x40 (i.e. the other no-MMU
platform with a defconfig file), this patch would introduce a change
because arch/arm/mach-at91/Makefile.boot defines
zreladdr-y += 0x20008000
but CONFIG_PAGE_OFFSET=0x01000000. I think that's a bug and my patch
does the right thing. Note that the at91x40 case isn't fixed though.
Best regards
Uwe
[1] http://git.kernel.org/cgit/linux/kernel/git/arnd/playground.git/?h=randconfig, commit:e65d61db588a057b5cbc3ba9bc8110819e05d748
arch/arm/boot/Makefile | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
index ec2f8065f955..2d935dd098e5 100644
--- a/arch/arm/boot/Makefile
+++ b/arch/arm/boot/Makefile
@@ -15,6 +15,10 @@ ifneq ($(MACHINE),)
include $(srctree)/$(MACHINE)/Makefile.boot
endif
+ifeq ($(zreladdr-y)$(CONFIG_MMU),)
+zreladdr-y := $(CONFIG_PAGE_OFFSET)+$(TEXT_OFFSET)
+endif
+
# Note: the following conditions must always be true:
# ZRELADDR == virt_to_phys(PAGE_OFFSET + TEXT_OFFSET)
# PARAMS_PHYS must be within 4MB of ZRELADDR
--
1.9.0
^ permalink raw reply related [flat|nested] 205+ messages in thread
* [PATCH 11/62] ARM: ep93xx: export ep93xx_chip_revision
2014-03-19 19:28 ` Arnd Bergmann
` (10 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-19 20:15 ` Hartley Sweeten
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
ep93xx_chip_revision is used by the pata_ep93xx driver,
which can be a loadable module. Exporting the symbol
avoids a link error in this case.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Ryan Mallon <rmallon@gmail.com>
---
arch/arm/mach-ep93xx/core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-ep93xx/core.c b/arch/arm/mach-ep93xx/core.c
index 6c70547..0e571f1 100644
--- a/arch/arm/mach-ep93xx/core.c
+++ b/arch/arm/mach-ep93xx/core.c
@@ -242,6 +242,7 @@ unsigned int ep93xx_chip_revision(void)
v >>= EP93XX_SYSCON_SYSCFG_REV_SHIFT;
return v;
}
+EXPORT_SYMBOL_GPL(ep93xx_chip_revision);
/*************************************************************************
* EP93xx GPIO
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 11/62] ARM: ep93xx: export ep93xx_chip_revision
2014-03-19 19:29 ` [PATCH 11/62] ARM: ep93xx: export ep93xx_chip_revision Arnd Bergmann
@ 2014-03-19 20:15 ` Hartley Sweeten
0 siblings, 0 replies; 205+ messages in thread
From: Hartley Sweeten @ 2014-03-19 20:15 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday, March 19, 2014 12:29 PM, Arnd Bergmann wrote:
> ep93xx_chip_revision is used by the pata_ep93xx driver,
> which can be a loadable module. Exporting the symbol
> avoids a link error in this case.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Hartley Sweeten <hsweeten@visionengravers.com>
> Cc: Ryan Mallon <rmallon@gmail.com>
> ---
> arch/arm/mach-ep93xx/core.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-ep93xx/core.c b/arch/arm/mach-ep93xx/core.c
> index 6c70547..0e571f1 100644
> --- a/arch/arm/mach-ep93xx/core.c
> +++ b/arch/arm/mach-ep93xx/core.c
> @@ -242,6 +242,7 @@ unsigned int ep93xx_chip_revision(void)
> v >>= EP93XX_SYSCON_SYSCFG_REV_SHIFT;
> return v;
> }
> +EXPORT_SYMBOL_GPL(ep93xx_chip_revision);
>
> /*************************************************************************
> * EP93xx GPIO
Good catch. Thanks.
Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 12/62] ARM: hisi: fix building without CONFIG_HOTPLUG_CPU
2014-03-19 19:28 ` Arnd Bergmann
` (11 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-20 1:49 ` Haojian Zhuang
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
The hisi SMP code always uses the hi3xxx_set_cpu() function
defined in the hotplug.c file, so we cannot build without
this when CONFIG_SMP is enabled. This patch slightly restructures
the code so we always build the parts of hotplug.c that we need
but just leave out the CPU disable logic if CONFIG_HOTPLUG_CPU
is turned off.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
---
arch/arm/mach-hisi/Makefile | 3 +--
arch/arm/mach-hisi/hotplug.c | 2 ++
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-hisi/Makefile b/arch/arm/mach-hisi/Makefile
index 6870058..2ae1b59 100644
--- a/arch/arm/mach-hisi/Makefile
+++ b/arch/arm/mach-hisi/Makefile
@@ -3,5 +3,4 @@
#
obj-y += hisilicon.o
-obj-$(CONFIG_SMP) += platsmp.o
-obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
+obj-$(CONFIG_SMP) += platsmp.o hotplug.o
diff --git a/arch/arm/mach-hisi/hotplug.c b/arch/arm/mach-hisi/hotplug.c
index b909854..abd441b 100644
--- a/arch/arm/mach-hisi/hotplug.c
+++ b/arch/arm/mach-hisi/hotplug.c
@@ -178,6 +178,7 @@ static inline void cpu_enter_lowpower(void)
: "cc");
}
+#ifdef CONFIG_HOTPLUG_CPU
void hi3xxx_cpu_die(unsigned int cpu)
{
cpu_enter_lowpower();
@@ -198,3 +199,4 @@ int hi3xxx_cpu_kill(unsigned int cpu)
hi3xxx_set_cpu(cpu, false);
return 1;
}
+#endif
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 12/62] ARM: hisi: fix building without CONFIG_HOTPLUG_CPU
2014-03-19 19:29 ` [PATCH 12/62] ARM: hisi: fix building without CONFIG_HOTPLUG_CPU Arnd Bergmann
@ 2014-03-20 1:49 ` Haojian Zhuang
0 siblings, 0 replies; 205+ messages in thread
From: Haojian Zhuang @ 2014-03-20 1:49 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Mar 20, 2014 at 3:29 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> The hisi SMP code always uses the hi3xxx_set_cpu() function
> defined in the hotplug.c file, so we cannot build without
> this when CONFIG_SMP is enabled. This patch slightly restructures
> the code so we always build the parts of hotplug.c that we need
> but just leave out the CPU disable logic if CONFIG_HOTPLUG_CPU
> is turned off.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
> ---
> arch/arm/mach-hisi/Makefile | 3 +--
> arch/arm/mach-hisi/hotplug.c | 2 ++
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-hisi/Makefile b/arch/arm/mach-hisi/Makefile
> index 6870058..2ae1b59 100644
> --- a/arch/arm/mach-hisi/Makefile
> +++ b/arch/arm/mach-hisi/Makefile
> @@ -3,5 +3,4 @@
> #
>
> obj-y += hisilicon.o
> -obj-$(CONFIG_SMP) += platsmp.o
> -obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
> +obj-$(CONFIG_SMP) += platsmp.o hotplug.o
> diff --git a/arch/arm/mach-hisi/hotplug.c b/arch/arm/mach-hisi/hotplug.c
> index b909854..abd441b 100644
> --- a/arch/arm/mach-hisi/hotplug.c
> +++ b/arch/arm/mach-hisi/hotplug.c
> @@ -178,6 +178,7 @@ static inline void cpu_enter_lowpower(void)
> : "cc");
> }
>
> +#ifdef CONFIG_HOTPLUG_CPU
> void hi3xxx_cpu_die(unsigned int cpu)
> {
> cpu_enter_lowpower();
> @@ -198,3 +199,4 @@ int hi3xxx_cpu_kill(unsigned int cpu)
> hi3xxx_set_cpu(cpu, false);
> return 1;
> }
> +#endif
> --
> 1.8.3.2
>
Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 13/62] ARM: hisi: select HAVE_ARM_SCU only for SMP
2014-03-19 19:28 ` Arnd Bergmann
` (12 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-20 1:47 ` Haojian Zhuang
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
The SCU code does not build unless we are compiling
an SMP kernel. This does the same as every other
platform with an SCU.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
---
arch/arm/mach-hisi/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-hisi/Kconfig b/arch/arm/mach-hisi/Kconfig
index 9d0a87b..feee4db 100644
--- a/arch/arm/mach-hisi/Kconfig
+++ b/arch/arm/mach-hisi/Kconfig
@@ -4,7 +4,7 @@ config ARCH_HI3xxx
select ARM_GIC
select ARM_TIMER_SP804
select CACHE_L2X0
- select HAVE_ARM_SCU
+ select HAVE_ARM_SCU if SMP
select HAVE_ARM_TWD if SMP
select PINCTRL
select PINCTRL_SINGLE
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 13/62] ARM: hisi: select HAVE_ARM_SCU only for SMP
2014-03-19 19:29 ` [PATCH 13/62] ARM: hisi: select HAVE_ARM_SCU only for SMP Arnd Bergmann
@ 2014-03-20 1:47 ` Haojian Zhuang
0 siblings, 0 replies; 205+ messages in thread
From: Haojian Zhuang @ 2014-03-20 1:47 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Mar 20, 2014 at 3:29 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> The SCU code does not build unless we are compiling
> an SMP kernel. This does the same as every other
> platform with an SCU.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
> ---
> arch/arm/mach-hisi/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-hisi/Kconfig b/arch/arm/mach-hisi/Kconfig
> index 9d0a87b..feee4db 100644
> --- a/arch/arm/mach-hisi/Kconfig
> +++ b/arch/arm/mach-hisi/Kconfig
> @@ -4,7 +4,7 @@ config ARCH_HI3xxx
> select ARM_GIC
> select ARM_TIMER_SP804
> select CACHE_L2X0
> - select HAVE_ARM_SCU
> + select HAVE_ARM_SCU if SMP
> select HAVE_ARM_TWD if SMP
> select PINCTRL
> select PINCTRL_SINGLE
> --
> 1.8.3.2
>
Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 14/62] ARM: imx: imx6q_set_lpm is only defined for CONFIG_PM=y
2014-03-19 19:28 ` Arnd Bergmann
` (13 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-20 6:50 ` Shawn Guo
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
This ensures that we only call imx6q_set_lpm if CONFIG_PM
is enabled and we are building the pm-imx6q.c file.
Another fix that has been suggested for this is to always
build this file conditionally build only the parts of it
that are relevant only to CONFIG_PM.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Shawn Guo <shawn.guo@freescale.com>
Cc: Sascha Hauer <kernel@pengutronix.de>
---
arch/arm/mach-imx/clk-imx6q.c | 3 ++-
arch/arm/mach-imx/clk-imx6sl.c | 3 ++-
arch/arm/mach-imx/cpuidle-imx6sl.c | 3 +++
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index b0e7f9d..133b23e 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -478,7 +478,8 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
clk_set_parent(clk[lvds1_sel], clk[sata_ref]);
/* Set initial power mode */
- imx6q_set_lpm(WAIT_CLOCKED);
+ if (IS_ENABLED(CONFIG_PM))
+ imx6q_set_lpm(WAIT_CLOCKED);
np = of_find_compatible_node(NULL, NULL, "fsl,imx6q-gpt");
base = of_iomap(np, 0);
diff --git a/arch/arm/mach-imx/clk-imx6sl.c b/arch/arm/mach-imx/clk-imx6sl.c
index f7073c0..a882bdf 100644
--- a/arch/arm/mach-imx/clk-imx6sl.c
+++ b/arch/arm/mach-imx/clk-imx6sl.c
@@ -382,7 +382,8 @@ static void __init imx6sl_clocks_init(struct device_node *ccm_node)
clk_set_parent(clks[IMX6SL_CLK_SPDIF0_SEL], clks[IMX6SL_CLK_PLL3_PFD3]);
/* Set initial power mode */
- imx6q_set_lpm(WAIT_CLOCKED);
+ if (IS_ENABLED(CONFIG_PM))
+ imx6q_set_lpm(WAIT_CLOCKED);
np = of_find_compatible_node(NULL, NULL, "fsl,imx6sl-gpt");
base = of_iomap(np, 0);
diff --git a/arch/arm/mach-imx/cpuidle-imx6sl.c b/arch/arm/mach-imx/cpuidle-imx6sl.c
index d4b6b81..c9a6aa8 100644
--- a/arch/arm/mach-imx/cpuidle-imx6sl.c
+++ b/arch/arm/mach-imx/cpuidle-imx6sl.c
@@ -53,5 +53,8 @@ static struct cpuidle_driver imx6sl_cpuidle_driver = {
int __init imx6sl_cpuidle_init(void)
{
+ if (!IS_ENABLED(CONFIG_PM))
+ return -ENOSYS;
+
return cpuidle_register(&imx6sl_cpuidle_driver, NULL);
}
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 14/62] ARM: imx: imx6q_set_lpm is only defined for CONFIG_PM=y
2014-03-19 19:29 ` [PATCH 14/62] ARM: imx: imx6q_set_lpm is only defined for CONFIG_PM=y Arnd Bergmann
@ 2014-03-20 6:50 ` Shawn Guo
0 siblings, 0 replies; 205+ messages in thread
From: Shawn Guo @ 2014-03-20 6:50 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Mar 19, 2014 at 08:29:11PM +0100, Arnd Bergmann wrote:
> This ensures that we only call imx6q_set_lpm if CONFIG_PM
> is enabled and we are building the pm-imx6q.c file.
>
> Another fix that has been suggested for this is to always
> build this file conditionally build only the parts of it
> that are relevant only to CONFIG_PM.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Shawn Guo <shawn.guo@freescale.com>
> Cc: Sascha Hauer <kernel@pengutronix.de>
I think this should have been fixed by commit 28a9f3b (ARM: imx6: build
pm-imx6q.c independently of CONFIG_PM) on mainline.
Shawn
> ---
> arch/arm/mach-imx/clk-imx6q.c | 3 ++-
> arch/arm/mach-imx/clk-imx6sl.c | 3 ++-
> arch/arm/mach-imx/cpuidle-imx6sl.c | 3 +++
> 3 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
> index b0e7f9d..133b23e 100644
> --- a/arch/arm/mach-imx/clk-imx6q.c
> +++ b/arch/arm/mach-imx/clk-imx6q.c
> @@ -478,7 +478,8 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
> clk_set_parent(clk[lvds1_sel], clk[sata_ref]);
>
> /* Set initial power mode */
> - imx6q_set_lpm(WAIT_CLOCKED);
> + if (IS_ENABLED(CONFIG_PM))
> + imx6q_set_lpm(WAIT_CLOCKED);
>
> np = of_find_compatible_node(NULL, NULL, "fsl,imx6q-gpt");
> base = of_iomap(np, 0);
> diff --git a/arch/arm/mach-imx/clk-imx6sl.c b/arch/arm/mach-imx/clk-imx6sl.c
> index f7073c0..a882bdf 100644
> --- a/arch/arm/mach-imx/clk-imx6sl.c
> +++ b/arch/arm/mach-imx/clk-imx6sl.c
> @@ -382,7 +382,8 @@ static void __init imx6sl_clocks_init(struct device_node *ccm_node)
> clk_set_parent(clks[IMX6SL_CLK_SPDIF0_SEL], clks[IMX6SL_CLK_PLL3_PFD3]);
>
> /* Set initial power mode */
> - imx6q_set_lpm(WAIT_CLOCKED);
> + if (IS_ENABLED(CONFIG_PM))
> + imx6q_set_lpm(WAIT_CLOCKED);
>
> np = of_find_compatible_node(NULL, NULL, "fsl,imx6sl-gpt");
> base = of_iomap(np, 0);
> diff --git a/arch/arm/mach-imx/cpuidle-imx6sl.c b/arch/arm/mach-imx/cpuidle-imx6sl.c
> index d4b6b81..c9a6aa8 100644
> --- a/arch/arm/mach-imx/cpuidle-imx6sl.c
> +++ b/arch/arm/mach-imx/cpuidle-imx6sl.c
> @@ -53,5 +53,8 @@ static struct cpuidle_driver imx6sl_cpuidle_driver = {
>
> int __init imx6sl_cpuidle_init(void)
> {
> + if (!IS_ENABLED(CONFIG_PM))
> + return -ENOSYS;
> +
> return cpuidle_register(&imx6sl_cpuidle_driver, NULL);
> }
> --
> 1.8.3.2
>
>
>
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 15/62] ARM: ixp4xx/omixp: always include linux/leds.h
2014-03-19 19:28 ` Arnd Bergmann
` (14 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-23 0:54 ` Krzysztof Halasa
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
The omixp board code unconditionally defines a gpio-led
device, but for some reason includes the header file
for this only if CONFIG_LEDS_CLASS is enabled, causing
a build error otherwise.
Removing the #ifdef fixes the build error with no downsides
whatsoever.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Imre Kaloz <kaloz@openwrt.org>
Cc: Krzysztof Halasa <khc@pm.waw.pl>
---
arch/arm/mach-ixp4xx/omixp-setup.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/mach-ixp4xx/omixp-setup.c b/arch/arm/mach-ixp4xx/omixp-setup.c
index 75ef03d..2d494b4 100644
--- a/arch/arm/mach-ixp4xx/omixp-setup.c
+++ b/arch/arm/mach-ixp4xx/omixp-setup.c
@@ -17,9 +17,7 @@
#include <linux/serial_8250.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/partitions.h>
-#ifdef CONFIG_LEDS_CLASS
#include <linux/leds.h>
-#endif
#include <asm/setup.h>
#include <asm/memory.h>
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 16/62] ARM: ixp4xx: avoid use of PCIBIOS_MIN_MEM in io.h
2014-03-19 19:28 ` Arnd Bergmann
` (15 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-23 0:47 ` Krzysztof Halasa
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
When using CONFIG_IXP4XX_INDIRECT_PCI, we run into a recursive
header file dependency between mach/io.h and asm/pci.h, resulting
in a build failure:
mach-ixp4xx/include/mach/io.h: In function 'is_pci_memory':
mach-ixp4xx/include/mach/io.h:53:18: error: 'PCIBIOS_MIN_MEM' undeclared (first use in this function)
return (addr >= PCIBIOS_MIN_MEM) && (addr <= 0x4FFFFFFF);
^
mach-ixp4xx/include/mach/io.h:53:18: note: each undeclared identifier is reported only once for each function it appears in
We can work around this by referencing the pcibios_min_mem variable
directly through an extern declaration, rather than using the macro.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Imre Kaloz <kaloz@openwrt.org>
Cc: Krzysztof Halasa <khc@pm.waw.pl>
---
arch/arm/mach-ixp4xx/include/mach/io.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-ixp4xx/include/mach/io.h b/arch/arm/mach-ixp4xx/include/mach/io.h
index 5cf30d1..559c69a 100644
--- a/arch/arm/mach-ixp4xx/include/mach/io.h
+++ b/arch/arm/mach-ixp4xx/include/mach/io.h
@@ -48,9 +48,10 @@ extern int ixp4xx_pci_write(u32 addr, u32 cmd, u32 data);
* fallback to the default.
*/
+extern unsigned long pcibios_min_mem;
static inline int is_pci_memory(u32 addr)
{
- return (addr >= PCIBIOS_MIN_MEM) && (addr <= 0x4FFFFFFF);
+ return (addr >= pcibios_min_mem) && (addr <= 0x4FFFFFFF);
}
#define writeb(v, p) __indirect_writeb(v, p)
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 16/62] ARM: ixp4xx: avoid use of PCIBIOS_MIN_MEM in io.h
2014-03-19 19:29 ` [PATCH 16/62] ARM: ixp4xx: avoid use of PCIBIOS_MIN_MEM in io.h Arnd Bergmann
@ 2014-03-23 0:47 ` Krzysztof Halasa
0 siblings, 0 replies; 205+ messages in thread
From: Krzysztof Halasa @ 2014-03-23 0:47 UTC (permalink / raw)
To: linux-arm-kernel
Arnd Bergmann <arnd@arndb.de> writes:
> When using CONFIG_IXP4XX_INDIRECT_PCI, we run into a recursive
> header file dependency between mach/io.h and asm/pci.h, resulting
> in a build failure:
> +++ b/arch/arm/mach-ixp4xx/include/mach/io.h
> @@ -48,9 +48,10 @@ extern int ixp4xx_pci_write(u32 addr, u32 cmd, u32 data);
> * fallback to the default.
> */
>
> +extern unsigned long pcibios_min_mem;
> static inline int is_pci_memory(u32 addr)
> {
> - return (addr >= PCIBIOS_MIN_MEM) && (addr <= 0x4FFFFFFF);
> + return (addr >= pcibios_min_mem) && (addr <= 0x4FFFFFFF);
> }
>
Not that I like externs very much, but since we're fixing things...
Polishing may be done later.
Acked-by: Krzysztof Halasa <khc@pm.waw.pl>
--
Krzysztof Halasa
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 17/62] ARM: ixp4xx: fix gpio rework
2014-03-19 19:28 ` Arnd Bergmann
` (16 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-23 0:42 ` Krzysztof Halasa
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
Commit 098e30f6558f8 "ARM: ixp4xx: stop broadcasting the custom GPIO API"
changed the internal gpio code of ixp4xx to be accessible only from
common.c, but unfortunately that broke the Goramo MultiLink code, which
uses this API.
This tries to restore the previous state without exposing the
API globally again. A better solution might be needed.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Krzysztof Halasa <khc@pm.waw.pl>
Cc: Imre Kaloz <kaloz@openwrt.org>
---
arch/arm/mach-ixp4xx/common.c | 6 +++---
arch/arm/mach-ixp4xx/goramo_mlr.c | 7 +++++++
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-ixp4xx/common.c b/arch/arm/mach-ixp4xx/common.c
index bffbce4..d628b3d 100644
--- a/arch/arm/mach-ixp4xx/common.c
+++ b/arch/arm/mach-ixp4xx/common.c
@@ -110,7 +110,7 @@ void __init ixp4xx_map_io(void)
#define IXP4XX_GPIO_CLK_0 14
#define IXP4XX_GPIO_CLK_1 15
-static void gpio_line_config(u8 line, u32 direction)
+void gpio_line_config(u8 line, u32 direction)
{
if (direction == IXP4XX_GPIO_IN)
*IXP4XX_GPIO_GPOER |= (1 << line);
@@ -118,12 +118,12 @@ static void gpio_line_config(u8 line, u32 direction)
*IXP4XX_GPIO_GPOER &= ~(1 << line);
}
-static void gpio_line_get(u8 line, int *value)
+void gpio_line_get(u8 line, int *value)
{
*value = (*IXP4XX_GPIO_GPINR >> line) & 0x1;
}
-static void gpio_line_set(u8 line, int value)
+void gpio_line_set(u8 line, int value)
{
if (value == IXP4XX_GPIO_HIGH)
*IXP4XX_GPIO_GPOUTR |= (1 << line);
diff --git a/arch/arm/mach-ixp4xx/goramo_mlr.c b/arch/arm/mach-ixp4xx/goramo_mlr.c
index e54ff491..5a635c6 100644
--- a/arch/arm/mach-ixp4xx/goramo_mlr.c
+++ b/arch/arm/mach-ixp4xx/goramo_mlr.c
@@ -17,6 +17,13 @@
#include <asm/mach/pci.h>
#include <asm/system_info.h>
+#define IXP4XX_GPIO_OUT 0x1
+#define IXP4XX_GPIO_IN 0x2
+
+void gpio_line_config(u8 line, u32 direction);
+void gpio_line_get(u8 line, int *value);
+void gpio_line_set(u8 line, int value);
+
#define SLOT_ETHA 0x0B /* IDSEL = AD21 */
#define SLOT_ETHB 0x0C /* IDSEL = AD20 */
#define SLOT_MPCI 0x0D /* IDSEL = AD19 */
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 17/62] ARM: ixp4xx: fix gpio rework
2014-03-19 19:29 ` [PATCH 17/62] ARM: ixp4xx: fix gpio rework Arnd Bergmann
@ 2014-03-23 0:42 ` Krzysztof Halasa
0 siblings, 0 replies; 205+ messages in thread
From: Krzysztof Halasa @ 2014-03-23 0:42 UTC (permalink / raw)
To: linux-arm-kernel
Arnd Bergmann <arnd@arndb.de> writes:
> Commit 098e30f6558f8 "ARM: ixp4xx: stop broadcasting the custom GPIO API"
> changed the internal gpio code of ixp4xx to be accessible only from
> common.c, but unfortunately that broke the Goramo MultiLink code, which
> uses this API.
>
> This tries to restore the previous state without exposing the
> API globally again. A better solution might be needed.
I think making the changes similar to those done to other IXP4xx
platforms is, indeed, preferred. Patch posted.
--
Krzysztof Halasa
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 18/62] ARM: ks8695/og: make PCI setup conditional
2014-03-19 19:28 ` Arnd Bergmann
` (17 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-19 23:20 ` Greg Ungerer
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
The 'og' machine tries to always initialized the PCI code, but that
may be disabled in Kconfig, leading to a build error.
This patch changes the code to use the same Kconfig symbol to decide
about calling the ks8695_init_pci function at build time that we
use to decide about building the ks8695 PCI support.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Ungerer <gerg@uclinux.org>
---
arch/arm/mach-ks8695/board-og.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-ks8695/board-og.c b/arch/arm/mach-ks8695/board-og.c
index 002bc61..f265816 100644
--- a/arch/arm/mach-ks8695/board-og.c
+++ b/arch/arm/mach-ks8695/board-og.c
@@ -44,7 +44,8 @@ static void __init og_register_pci(void)
if (machine_is_im4004())
ks8695_gpio_interrupt(KS8695_GPIO_1, IRQ_TYPE_LEVEL_LOW);
- ks8695_init_pci(&og_pci);
+ if (IS_ENABLED(CONFIG_PCI))
+ ks8695_init_pci(&og_pci);
}
/*
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 18/62] ARM: ks8695/og: make PCI setup conditional
2014-03-19 19:29 ` [PATCH 18/62] ARM: ks8695/og: make PCI setup conditional Arnd Bergmann
@ 2014-03-19 23:20 ` Greg Ungerer
0 siblings, 0 replies; 205+ messages in thread
From: Greg Ungerer @ 2014-03-19 23:20 UTC (permalink / raw)
To: linux-arm-kernel
On 20/03/14 05:29, Arnd Bergmann wrote:
> The 'og' machine tries to always initialized the PCI code, but that
> may be disabled in Kconfig, leading to a build error.
>
> This patch changes the code to use the same Kconfig symbol to decide
> about calling the ks8695_init_pci function at build time that we
> use to decide about building the ks8695 PCI support.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Greg Ungerer <gerg@uclinux.org>
Looks good.
Acked-by: Greg Ungerer <gerg@uclinux.org>
> arch/arm/mach-ks8695/board-og.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-ks8695/board-og.c b/arch/arm/mach-ks8695/board-og.c
> index 002bc61..f265816 100644
> --- a/arch/arm/mach-ks8695/board-og.c
> +++ b/arch/arm/mach-ks8695/board-og.c
> @@ -44,7 +44,8 @@ static void __init og_register_pci(void)
> if (machine_is_im4004())
> ks8695_gpio_interrupt(KS8695_GPIO_1, IRQ_TYPE_LEVEL_LOW);
>
> - ks8695_init_pci(&og_pci);
> + if (IS_ENABLED(CONFIG_PCI))
> + ks8695_init_pci(&og_pci);
> }
>
> /*
>
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 19/62] ARM: lpc32xx: export lpc32xx_return_iram_size
2014-03-19 19:28 ` Arnd Bergmann
` (18 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-19 20:05 ` Roland Stigge
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
This symbol is used by the lpc_eth driver, which may
be a loadable module.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Roland Stigge <stigge@antcom.de>
---
arch/arm/mach-lpc32xx/common.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-lpc32xx/common.c b/arch/arm/mach-lpc32xx/common.c
index d7aa54c..de03620 100644
--- a/arch/arm/mach-lpc32xx/common.c
+++ b/arch/arm/mach-lpc32xx/common.c
@@ -99,6 +99,7 @@ u32 lpc32xx_return_iram_size(void)
return iram_size;
}
+EXPORT_SYMBOL_GPL(lpc32xx_return_iram_size);
/*
* Computes PLL rate from PLL register and input clock
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 19/62] ARM: lpc32xx: export lpc32xx_return_iram_size
2014-03-19 19:29 ` [PATCH 19/62] ARM: lpc32xx: export lpc32xx_return_iram_size Arnd Bergmann
@ 2014-03-19 20:05 ` Roland Stigge
0 siblings, 0 replies; 205+ messages in thread
From: Roland Stigge @ 2014-03-19 20:05 UTC (permalink / raw)
To: linux-arm-kernel
On 19/03/14 20:29, Arnd Bergmann wrote:
> This symbol is used by the lpc_eth driver, which may
> be a loadable module.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Roland Stigge <stigge@antcom.de>
> ---
> arch/arm/mach-lpc32xx/common.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-lpc32xx/common.c b/arch/arm/mach-lpc32xx/common.c
> index d7aa54c..de03620 100644
> --- a/arch/arm/mach-lpc32xx/common.c
> +++ b/arch/arm/mach-lpc32xx/common.c
> @@ -99,6 +99,7 @@ u32 lpc32xx_return_iram_size(void)
>
> return iram_size;
> }
> +EXPORT_SYMBOL_GPL(lpc32xx_return_iram_size);
>
> /*
> * Computes PLL rate from PLL register and input clock
>
Of course; thanks!
Acked-by: Roland Stigge <stigge@antcom.de>
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 20/62] ARM: msm: add missing include of linux/module.h
2014-03-19 19:28 ` Arnd Bergmann
` (19 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-19 21:11 ` David Brown
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
After the restructuring of the module.h and init.h headers,
we now need to include this explicitly here.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: David Brown <davidb@codeaurora.org>
Cc: Daniel Walker <dwalker@fifo99.com>
Cc: Bryan Huntsman <bryanh@codeaurora.org>
---
arch/arm/mach-msm/dma.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-msm/dma.c b/arch/arm/mach-msm/dma.c
index f8f6adf..ba62f02 100644
--- a/arch/arm/mach-msm/dma.c
+++ b/arch/arm/mach-msm/dma.c
@@ -18,6 +18,7 @@
#include <linux/io.h>
#include <linux/interrupt.h>
#include <linux/completion.h>
+#include <linux/module.h>
#include <mach/dma.h>
#include <mach/msm_iomap.h>
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 20/62] ARM: msm: add missing include of linux/module.h
2014-03-19 19:29 ` [PATCH 20/62] ARM: msm: add missing include of linux/module.h Arnd Bergmann
@ 2014-03-19 21:11 ` David Brown
0 siblings, 0 replies; 205+ messages in thread
From: David Brown @ 2014-03-19 21:11 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Mar 19, 2014 at 08:29:17PM +0100, Arnd Bergmann wrote:
>After the restructuring of the module.h and init.h headers,
>we now need to include this explicitly here.
>
>Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>Cc: David Brown <davidb@codeaurora.org>
>Cc: Daniel Walker <dwalker@fifo99.com>
>Cc: Bryan Huntsman <bryanh@codeaurora.org>
>---
> arch/arm/mach-msm/dma.c | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: David Brown <davidb@codeaurora.org>
>diff --git a/arch/arm/mach-msm/dma.c b/arch/arm/mach-msm/dma.c
>index f8f6adf..ba62f02 100644
>--- a/arch/arm/mach-msm/dma.c
>+++ b/arch/arm/mach-msm/dma.c
>@@ -18,6 +18,7 @@
> #include <linux/io.h>
> #include <linux/interrupt.h>
> #include <linux/completion.h>
>+#include <linux/module.h>
> #include <mach/dma.h>
> #include <mach/msm_iomap.h>
>
>--
>1.8.3.2
>
--
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 21/62] ARM: msm: avoid calling debug_ll_addr on !MMU
2014-03-19 19:28 ` Arnd Bergmann
` (20 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-19 21:11 ` David Brown
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
MSM7X00A has an open-coded version of debug_ll_io_init so it
can use MT_DEVICE_NONSHARED as required by the platform.
However, this fails to build on no-MMU kernels because the
debug_ll_addr function is not available. Since the iotable_init
function doesn't actually do anyting in this configuration,
we can simply get away by enclosing the broken function call
in an #ifdef, which seems to be the least ugly workaround.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: David Brown <davidb@codeaurora.org>
Cc: Daniel Walker <dwalker@fifo99.com>
Cc: Bryan Huntsman <bryanh@codeaurora.org>
---
arch/arm/mach-msm/io.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-msm/io.c b/arch/arm/mach-msm/io.c
index adc8971..34e0947 100644
--- a/arch/arm/mach-msm/io.c
+++ b/arch/arm/mach-msm/io.c
@@ -78,8 +78,10 @@ void __init msm_map_common_io(void)
asm("mcr p15, 0, %0, c15, c2, 4" : : "r" (0));
#if defined(CONFIG_DEBUG_MSM_UART1) || defined(CONFIG_DEBUG_MSM_UART2) || \
defined(CONFIG_DEBUG_MSM_UART3)
+#ifdef CONFIG_MMU
debug_ll_addr(&msm_io_desc[size - 1].pfn,
&msm_io_desc[size - 1].virtual);
+#endif
msm_io_desc[size - 1].pfn = __phys_to_pfn(msm_io_desc[size - 1].pfn);
#endif
iotable_init(msm_io_desc, size);
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 21/62] ARM: msm: avoid calling debug_ll_addr on !MMU
2014-03-19 19:29 ` [PATCH 21/62] ARM: msm: avoid calling debug_ll_addr on !MMU Arnd Bergmann
@ 2014-03-19 21:11 ` David Brown
0 siblings, 0 replies; 205+ messages in thread
From: David Brown @ 2014-03-19 21:11 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Mar 19, 2014 at 08:29:18PM +0100, Arnd Bergmann wrote:
>MSM7X00A has an open-coded version of debug_ll_io_init so it
>can use MT_DEVICE_NONSHARED as required by the platform.
>
>However, this fails to build on no-MMU kernels because the
>debug_ll_addr function is not available. Since the iotable_init
>function doesn't actually do anyting in this configuration,
>we can simply get away by enclosing the broken function call
>in an #ifdef, which seems to be the least ugly workaround.
>
>Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>Cc: David Brown <davidb@codeaurora.org>
>Cc: Daniel Walker <dwalker@fifo99.com>
>Cc: Bryan Huntsman <bryanh@codeaurora.org>
>---
> arch/arm/mach-msm/io.c | 2 ++
> 1 file changed, 2 insertions(+)
Acked-by: David Brown <davidb@codeaurora.org>
>diff --git a/arch/arm/mach-msm/io.c b/arch/arm/mach-msm/io.c
>index adc8971..34e0947 100644
>--- a/arch/arm/mach-msm/io.c
>+++ b/arch/arm/mach-msm/io.c
>@@ -78,8 +78,10 @@ void __init msm_map_common_io(void)
> asm("mcr p15, 0, %0, c15, c2, 4" : : "r" (0));
> #if defined(CONFIG_DEBUG_MSM_UART1) || defined(CONFIG_DEBUG_MSM_UART2) || \
> defined(CONFIG_DEBUG_MSM_UART3)
>+#ifdef CONFIG_MMU
> debug_ll_addr(&msm_io_desc[size - 1].pfn,
> &msm_io_desc[size - 1].virtual);
>+#endif
> msm_io_desc[size - 1].pfn = __phys_to_pfn(msm_io_desc[size - 1].pfn);
> #endif
> iotable_init(msm_io_desc, size);
>--
>1.8.3.2
>
--
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 22/62] ARM: msm: export legacy DMA interfaces
2014-03-19 19:28 ` Arnd Bergmann
` (21 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-19 21:12 ` David Brown
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
The msm_sdcc MMC driver and the msm_serial_hs uart driver both
use the pre-dmaengine interfaces provided by the MSM platform.
Since these drivers can be loadable modules, we should export
the functions used in the drivers.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: David Brown <davidb@codeaurora.org>
Cc: Daniel Walker <dwalker@fifo99.com>
Cc: Bryan Huntsman <bryanh@codeaurora.org>
---
arch/arm/mach-msm/dma.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-msm/dma.c b/arch/arm/mach-msm/dma.c
index ba62f02..fb976246 100644
--- a/arch/arm/mach-msm/dma.c
+++ b/arch/arm/mach-msm/dma.c
@@ -78,6 +78,7 @@ void msm_dmov_stop_cmd(unsigned id, struct msm_dmov_cmd *cmd, int graceful)
{
writel((graceful << 31), DMOV_FLUSH0(id));
}
+EXPORT_SYMBOL_GPL(msm_dmov_stop_cmd);
void msm_dmov_enqueue_cmd(unsigned id, struct msm_dmov_cmd *cmd)
{
@@ -116,6 +117,7 @@ void msm_dmov_enqueue_cmd(unsigned id, struct msm_dmov_cmd *cmd)
}
spin_unlock_irqrestore(&msm_dmov_lock, irq_flags);
}
+EXPORT_SYMBOL_GPL(msm_dmov_enqueue_cmd);
struct msm_dmov_exec_cmdptr_cmd {
struct msm_dmov_cmd dmov_cmd;
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 22/62] ARM: msm: export legacy DMA interfaces
2014-03-19 19:29 ` [PATCH 22/62] ARM: msm: export legacy DMA interfaces Arnd Bergmann
@ 2014-03-19 21:12 ` David Brown
0 siblings, 0 replies; 205+ messages in thread
From: David Brown @ 2014-03-19 21:12 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Mar 19, 2014 at 08:29:19PM +0100, Arnd Bergmann wrote:
>The msm_sdcc MMC driver and the msm_serial_hs uart driver both
>use the pre-dmaengine interfaces provided by the MSM platform.
>
>Since these drivers can be loadable modules, we should export
>the functions used in the drivers.
>
>Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>Cc: David Brown <davidb@codeaurora.org>
>Cc: Daniel Walker <dwalker@fifo99.com>
>Cc: Bryan Huntsman <bryanh@codeaurora.org>
>---
> arch/arm/mach-msm/dma.c | 2 ++
> 1 file changed, 2 insertions(+)
Acked-by: David Brown <davidb@codeaurora.org>
--
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 23/62] ARM: omap1: fix building without 32K_TIMER
2014-03-19 19:28 ` Arnd Bergmann
@ 2014-03-19 19:29 ` Arnd Bergmann
-1 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: arm; +Cc: linux-arm-kernel, Arnd Bergmann, linux-omap, Tony Lindgren
If we enable CONFIG_OMAP_MPU_TIMER and CONFIG_OMAP_DM_TIMER but
not CONFIG_OMAP_32K_TIMER on OMAP1, we currently get this build error:
mach-omap1/pm.c: In function 'omap1_pm_idle':
mach-omap1/pm.c:123:9: error: 'enable_dyn_sleep' undeclared (first use in this function)
while (enable_dyn_sleep) {
^
mach-omap1/pm.c:123:9: note: each undeclared identifier is reported only once for each function it appears in
This attempts to fix the #ifdef logic to deal with all combinations
of timers.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: linux-omap@vger.kernel.org
Cc: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap1/pm.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c
index 40a1ae3..7dff68e 100644
--- a/arch/arm/mach-omap1/pm.c
+++ b/arch/arm/mach-omap1/pm.c
@@ -71,10 +71,10 @@ static unsigned int mpui7xx_sleep_save[MPUI7XX_SLEEP_SAVE_SIZE];
static unsigned int mpui1510_sleep_save[MPUI1510_SLEEP_SAVE_SIZE];
static unsigned int mpui1610_sleep_save[MPUI1610_SLEEP_SAVE_SIZE];
-#ifdef CONFIG_OMAP_32K_TIMER
-
static unsigned short enable_dyn_sleep = 1;
+#if defined(CONFIG_OMAP_32K_TIMER) || defined(CONFIG_OMAP_MPU_TIMER)
+
static ssize_t idle_show(struct kobject *kobj, struct kobj_attribute *attr,
char *buf)
{
@@ -643,7 +643,7 @@ static const struct platform_suspend_ops omap_pm_ops = {
static int __init omap_pm_init(void)
{
-#ifdef CONFIG_OMAP_32K_TIMER
+#if defined(CONFIG_OMAP_32K_TIMER) || defined(CONFIG_OMAP_MPU_TIMER)
int error;
#endif
@@ -700,7 +700,7 @@ static int __init omap_pm_init(void)
omap_pm_init_debugfs();
#endif
-#ifdef CONFIG_OMAP_32K_TIMER
+#if defined(CONFIG_OMAP_32K_TIMER) || defined(CONFIG_OMAP_MPU_TIMER)
error = sysfs_create_file(power_kobj, &sleep_while_idle_attr.attr);
if (error)
printk(KERN_ERR "sysfs_create_file failed: %d\n", error);
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 23/62] ARM: omap1: fix building without 32K_TIMER
@ 2014-03-19 19:29 ` Arnd Bergmann
0 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
If we enable CONFIG_OMAP_MPU_TIMER and CONFIG_OMAP_DM_TIMER but
not CONFIG_OMAP_32K_TIMER on OMAP1, we currently get this build error:
mach-omap1/pm.c: In function 'omap1_pm_idle':
mach-omap1/pm.c:123:9: error: 'enable_dyn_sleep' undeclared (first use in this function)
while (enable_dyn_sleep) {
^
mach-omap1/pm.c:123:9: note: each undeclared identifier is reported only once for each function it appears in
This attempts to fix the #ifdef logic to deal with all combinations
of timers.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: linux-omap at vger.kernel.org
Cc: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap1/pm.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c
index 40a1ae3..7dff68e 100644
--- a/arch/arm/mach-omap1/pm.c
+++ b/arch/arm/mach-omap1/pm.c
@@ -71,10 +71,10 @@ static unsigned int mpui7xx_sleep_save[MPUI7XX_SLEEP_SAVE_SIZE];
static unsigned int mpui1510_sleep_save[MPUI1510_SLEEP_SAVE_SIZE];
static unsigned int mpui1610_sleep_save[MPUI1610_SLEEP_SAVE_SIZE];
-#ifdef CONFIG_OMAP_32K_TIMER
-
static unsigned short enable_dyn_sleep = 1;
+#if defined(CONFIG_OMAP_32K_TIMER) || defined(CONFIG_OMAP_MPU_TIMER)
+
static ssize_t idle_show(struct kobject *kobj, struct kobj_attribute *attr,
char *buf)
{
@@ -643,7 +643,7 @@ static const struct platform_suspend_ops omap_pm_ops = {
static int __init omap_pm_init(void)
{
-#ifdef CONFIG_OMAP_32K_TIMER
+#if defined(CONFIG_OMAP_32K_TIMER) || defined(CONFIG_OMAP_MPU_TIMER)
int error;
#endif
@@ -700,7 +700,7 @@ static int __init omap_pm_init(void)
omap_pm_init_debugfs();
#endif
-#ifdef CONFIG_OMAP_32K_TIMER
+#if defined(CONFIG_OMAP_32K_TIMER) || defined(CONFIG_OMAP_MPU_TIMER)
error = sysfs_create_file(power_kobj, &sleep_while_idle_attr.attr);
if (error)
printk(KERN_ERR "sysfs_create_file failed: %d\n", error);
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* Re: [PATCH 23/62] ARM: omap1: fix building without 32K_TIMER
2014-03-19 19:29 ` Arnd Bergmann
@ 2014-03-19 19:59 ` Felipe Balbi
-1 siblings, 0 replies; 205+ messages in thread
From: Felipe Balbi @ 2014-03-19 19:59 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: arm, linux-arm-kernel, linux-omap, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 2461 bytes --]
Hi,
On Wed, Mar 19, 2014 at 08:29:20PM +0100, Arnd Bergmann wrote:
> If we enable CONFIG_OMAP_MPU_TIMER and CONFIG_OMAP_DM_TIMER but
> not CONFIG_OMAP_32K_TIMER on OMAP1, we currently get this build error:
>
> mach-omap1/pm.c: In function 'omap1_pm_idle':
> mach-omap1/pm.c:123:9: error: 'enable_dyn_sleep' undeclared (first use in this function)
> while (enable_dyn_sleep) {
> ^
> mach-omap1/pm.c:123:9: note: each undeclared identifier is reported only once for each function it appears in
>
> This attempts to fix the #ifdef logic to deal with all combinations
> of timers.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: linux-omap@vger.kernel.org
> Cc: Tony Lindgren <tony@atomide.com>
I had sent a fix for months and months ago, what happened to it ?
> ---
> arch/arm/mach-omap1/pm.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c
> index 40a1ae3..7dff68e 100644
> --- a/arch/arm/mach-omap1/pm.c
> +++ b/arch/arm/mach-omap1/pm.c
> @@ -71,10 +71,10 @@ static unsigned int mpui7xx_sleep_save[MPUI7XX_SLEEP_SAVE_SIZE];
> static unsigned int mpui1510_sleep_save[MPUI1510_SLEEP_SAVE_SIZE];
> static unsigned int mpui1610_sleep_save[MPUI1610_SLEEP_SAVE_SIZE];
>
> -#ifdef CONFIG_OMAP_32K_TIMER
> -
> static unsigned short enable_dyn_sleep = 1;
>
> +#if defined(CONFIG_OMAP_32K_TIMER) || defined(CONFIG_OMAP_MPU_TIMER)
> +
> static ssize_t idle_show(struct kobject *kobj, struct kobj_attribute *attr,
> char *buf)
> {
> @@ -643,7 +643,7 @@ static const struct platform_suspend_ops omap_pm_ops = {
> static int __init omap_pm_init(void)
> {
>
> -#ifdef CONFIG_OMAP_32K_TIMER
> +#if defined(CONFIG_OMAP_32K_TIMER) || defined(CONFIG_OMAP_MPU_TIMER)
> int error;
> #endif
>
> @@ -700,7 +700,7 @@ static int __init omap_pm_init(void)
> omap_pm_init_debugfs();
> #endif
>
> -#ifdef CONFIG_OMAP_32K_TIMER
> +#if defined(CONFIG_OMAP_32K_TIMER) || defined(CONFIG_OMAP_MPU_TIMER)
> error = sysfs_create_file(power_kobj, &sleep_while_idle_attr.attr);
> if (error)
> printk(KERN_ERR "sysfs_create_file failed: %d\n", error);
> --
> 1.8.3.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 205+ messages in thread* [PATCH 23/62] ARM: omap1: fix building without 32K_TIMER
@ 2014-03-19 19:59 ` Felipe Balbi
0 siblings, 0 replies; 205+ messages in thread
From: Felipe Balbi @ 2014-03-19 19:59 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Wed, Mar 19, 2014 at 08:29:20PM +0100, Arnd Bergmann wrote:
> If we enable CONFIG_OMAP_MPU_TIMER and CONFIG_OMAP_DM_TIMER but
> not CONFIG_OMAP_32K_TIMER on OMAP1, we currently get this build error:
>
> mach-omap1/pm.c: In function 'omap1_pm_idle':
> mach-omap1/pm.c:123:9: error: 'enable_dyn_sleep' undeclared (first use in this function)
> while (enable_dyn_sleep) {
> ^
> mach-omap1/pm.c:123:9: note: each undeclared identifier is reported only once for each function it appears in
>
> This attempts to fix the #ifdef logic to deal with all combinations
> of timers.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: linux-omap at vger.kernel.org
> Cc: Tony Lindgren <tony@atomide.com>
I had sent a fix for months and months ago, what happened to it ?
> ---
> arch/arm/mach-omap1/pm.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c
> index 40a1ae3..7dff68e 100644
> --- a/arch/arm/mach-omap1/pm.c
> +++ b/arch/arm/mach-omap1/pm.c
> @@ -71,10 +71,10 @@ static unsigned int mpui7xx_sleep_save[MPUI7XX_SLEEP_SAVE_SIZE];
> static unsigned int mpui1510_sleep_save[MPUI1510_SLEEP_SAVE_SIZE];
> static unsigned int mpui1610_sleep_save[MPUI1610_SLEEP_SAVE_SIZE];
>
> -#ifdef CONFIG_OMAP_32K_TIMER
> -
> static unsigned short enable_dyn_sleep = 1;
>
> +#if defined(CONFIG_OMAP_32K_TIMER) || defined(CONFIG_OMAP_MPU_TIMER)
> +
> static ssize_t idle_show(struct kobject *kobj, struct kobj_attribute *attr,
> char *buf)
> {
> @@ -643,7 +643,7 @@ static const struct platform_suspend_ops omap_pm_ops = {
> static int __init omap_pm_init(void)
> {
>
> -#ifdef CONFIG_OMAP_32K_TIMER
> +#if defined(CONFIG_OMAP_32K_TIMER) || defined(CONFIG_OMAP_MPU_TIMER)
> int error;
> #endif
>
> @@ -700,7 +700,7 @@ static int __init omap_pm_init(void)
> omap_pm_init_debugfs();
> #endif
>
> -#ifdef CONFIG_OMAP_32K_TIMER
> +#if defined(CONFIG_OMAP_32K_TIMER) || defined(CONFIG_OMAP_MPU_TIMER)
> error = sysfs_create_file(power_kobj, &sleep_while_idle_attr.attr);
> if (error)
> printk(KERN_ERR "sysfs_create_file failed: %d\n", error);
> --
> 1.8.3.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140319/dbfd0ffe/attachment.sig>
^ permalink raw reply [flat|nested] 205+ messages in thread* Re: [PATCH 23/62] ARM: omap1: fix building without 32K_TIMER
2014-03-19 19:59 ` Felipe Balbi
@ 2014-03-19 20:01 ` Felipe Balbi
-1 siblings, 0 replies; 205+ messages in thread
From: Felipe Balbi @ 2014-03-19 20:01 UTC (permalink / raw)
To: Felipe Balbi
Cc: Arnd Bergmann, arm, linux-arm-kernel, linux-omap, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]
On Wed, Mar 19, 2014 at 02:59:13PM -0500, Felipe Balbi wrote:
> Hi,
>
> On Wed, Mar 19, 2014 at 08:29:20PM +0100, Arnd Bergmann wrote:
> > If we enable CONFIG_OMAP_MPU_TIMER and CONFIG_OMAP_DM_TIMER but
> > not CONFIG_OMAP_32K_TIMER on OMAP1, we currently get this build error:
> >
> > mach-omap1/pm.c: In function 'omap1_pm_idle':
> > mach-omap1/pm.c:123:9: error: 'enable_dyn_sleep' undeclared (first use in this function)
> > while (enable_dyn_sleep) {
> > ^
> > mach-omap1/pm.c:123:9: note: each undeclared identifier is reported only once for each function it appears in
> >
> > This attempts to fix the #ifdef logic to deal with all combinations
> > of timers.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: linux-omap@vger.kernel.org
> > Cc: Tony Lindgren <tony@atomide.com>
>
> I had sent a fix for months and months ago, what happened to it ?
Here
http://marc.info/?l=linux-omap&m=138963632408031&w=2
Tony, did you forget to send a pull request ?
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 205+ messages in thread* [PATCH 23/62] ARM: omap1: fix building without 32K_TIMER
@ 2014-03-19 20:01 ` Felipe Balbi
0 siblings, 0 replies; 205+ messages in thread
From: Felipe Balbi @ 2014-03-19 20:01 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Mar 19, 2014 at 02:59:13PM -0500, Felipe Balbi wrote:
> Hi,
>
> On Wed, Mar 19, 2014 at 08:29:20PM +0100, Arnd Bergmann wrote:
> > If we enable CONFIG_OMAP_MPU_TIMER and CONFIG_OMAP_DM_TIMER but
> > not CONFIG_OMAP_32K_TIMER on OMAP1, we currently get this build error:
> >
> > mach-omap1/pm.c: In function 'omap1_pm_idle':
> > mach-omap1/pm.c:123:9: error: 'enable_dyn_sleep' undeclared (first use in this function)
> > while (enable_dyn_sleep) {
> > ^
> > mach-omap1/pm.c:123:9: note: each undeclared identifier is reported only once for each function it appears in
> >
> > This attempts to fix the #ifdef logic to deal with all combinations
> > of timers.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: linux-omap at vger.kernel.org
> > Cc: Tony Lindgren <tony@atomide.com>
>
> I had sent a fix for months and months ago, what happened to it ?
Here
http://marc.info/?l=linux-omap&m=138963632408031&w=2
Tony, did you forget to send a pull request ?
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140319/1f1a2926/attachment-0001.sig>
^ permalink raw reply [flat|nested] 205+ messages in thread* Re: [PATCH 23/62] ARM: omap1: fix building without 32K_TIMER
2014-03-19 20:01 ` Felipe Balbi
@ 2014-03-19 20:34 ` Tony Lindgren
-1 siblings, 0 replies; 205+ messages in thread
From: Tony Lindgren @ 2014-03-19 20:34 UTC (permalink / raw)
To: Felipe Balbi; +Cc: Arnd Bergmann, arm, linux-arm-kernel, linux-omap
* Felipe Balbi <balbi@ti.com> [140319 13:06]:
> On Wed, Mar 19, 2014 at 02:59:13PM -0500, Felipe Balbi wrote:
> > Hi,
> >
> > On Wed, Mar 19, 2014 at 08:29:20PM +0100, Arnd Bergmann wrote:
> > > If we enable CONFIG_OMAP_MPU_TIMER and CONFIG_OMAP_DM_TIMER but
> > > not CONFIG_OMAP_32K_TIMER on OMAP1, we currently get this build error:
> > >
> > > mach-omap1/pm.c: In function 'omap1_pm_idle':
> > > mach-omap1/pm.c:123:9: error: 'enable_dyn_sleep' undeclared (first use in this function)
> > > while (enable_dyn_sleep) {
> > > ^
> > > mach-omap1/pm.c:123:9: note: each undeclared identifier is reported only once for each function it appears in
> > >
> > > This attempts to fix the #ifdef logic to deal with all combinations
> > > of timers.
> > >
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > Cc: linux-omap@vger.kernel.org
> > > Cc: Tony Lindgren <tony@atomide.com>
> >
> > I had sent a fix for months and months ago, what happened to it ?
>
> Here
>
> http://marc.info/?l=linux-omap&m=138963632408031&w=2
>
> Tony, did you forget to send a pull request ?
Hmm yes weird, can't see it in my omap-for-v3.14/fixes branch.
I must have gotten interrupted while applying and then probably
ran git reset --hard before committing.
Arnd, maybe pick up Felipe's earlier patch instead?
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply [flat|nested] 205+ messages in thread* [PATCH 23/62] ARM: omap1: fix building without 32K_TIMER
@ 2014-03-19 20:34 ` Tony Lindgren
0 siblings, 0 replies; 205+ messages in thread
From: Tony Lindgren @ 2014-03-19 20:34 UTC (permalink / raw)
To: linux-arm-kernel
* Felipe Balbi <balbi@ti.com> [140319 13:06]:
> On Wed, Mar 19, 2014 at 02:59:13PM -0500, Felipe Balbi wrote:
> > Hi,
> >
> > On Wed, Mar 19, 2014 at 08:29:20PM +0100, Arnd Bergmann wrote:
> > > If we enable CONFIG_OMAP_MPU_TIMER and CONFIG_OMAP_DM_TIMER but
> > > not CONFIG_OMAP_32K_TIMER on OMAP1, we currently get this build error:
> > >
> > > mach-omap1/pm.c: In function 'omap1_pm_idle':
> > > mach-omap1/pm.c:123:9: error: 'enable_dyn_sleep' undeclared (first use in this function)
> > > while (enable_dyn_sleep) {
> > > ^
> > > mach-omap1/pm.c:123:9: note: each undeclared identifier is reported only once for each function it appears in
> > >
> > > This attempts to fix the #ifdef logic to deal with all combinations
> > > of timers.
> > >
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > Cc: linux-omap at vger.kernel.org
> > > Cc: Tony Lindgren <tony@atomide.com>
> >
> > I had sent a fix for months and months ago, what happened to it ?
>
> Here
>
> http://marc.info/?l=linux-omap&m=138963632408031&w=2
>
> Tony, did you forget to send a pull request ?
Hmm yes weird, can't see it in my omap-for-v3.14/fixes branch.
I must have gotten interrupted while applying and then probably
ran git reset --hard before committing.
Arnd, maybe pick up Felipe's earlier patch instead?
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply [flat|nested] 205+ messages in thread* Re: [PATCH 23/62] ARM: omap1: fix building without 32K_TIMER
2014-03-19 20:34 ` Tony Lindgren
@ 2014-03-21 16:01 ` Arnd Bergmann
-1 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-21 16:01 UTC (permalink / raw)
To: Tony Lindgren; +Cc: Felipe Balbi, arm, linux-arm-kernel, linux-omap
On Wednesday 19 March 2014, Tony Lindgren wrote:
> * Felipe Balbi <balbi@ti.com> [140319 13:06]:
> > On Wed, Mar 19, 2014 at 02:59:13PM -0500, Felipe Balbi wrote:
> > > I had sent a fix for months and months ago, what happened to it ?
> >
> > Here
> >
> > http://marc.info/?l=linux-omap&m=138963632408031&w=2
> >
> > Tony, did you forget to send a pull request ?
>
> Hmm yes weird, can't see it in my omap-for-v3.14/fixes branch.
>
> I must have gotten interrupted while applying and then probably
> ran git reset --hard before committing.
>
> Arnd, maybe pick up Felipe's earlier patch instead?
>
> Acked-by: Tony Lindgren <tony@atomide.com>
Ok, using this version now, thanks!
Arnd
>From 64cdcf550319a37d1419aa6a87903e67b9d3d031 Mon Sep 17 00:00:00 2001
From: Felipe Balbi <balbi@ti.com>
Date: Sun, 16 Mar 2014 17:57:55 +0100
Subject: [PATCH] ARM: omap1: fix build when !CONFIG_OMAP_32K_TIMER
If CONFIG_OMAP_32K_TIMER isn't enabled, we will
try to use enable_dyn_sleep which wasn't defined
anywhere.
In order to fix the problem, we always define
enable_dyn_sleep as 0 when !CONFIG_OMAP_32K_TIMER.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c
index 40a1ae3..dbee729 100644
--- a/arch/arm/mach-omap1/pm.c
+++ b/arch/arm/mach-omap1/pm.c
@@ -71,7 +71,11 @@ static unsigned int mpui7xx_sleep_save[MPUI7XX_SLEEP_SAVE_SIZE];
static unsigned int mpui1510_sleep_save[MPUI1510_SLEEP_SAVE_SIZE];
static unsigned int mpui1610_sleep_save[MPUI1610_SLEEP_SAVE_SIZE];
-#ifdef CONFIG_OMAP_32K_TIMER
+#ifndef CONFIG_OMAP_32K_TIMER
+
+static unsigned short enable_dyn_sleep = 0;
+
+#else
static unsigned short enable_dyn_sleep = 1;
^ permalink raw reply related [flat|nested] 205+ messages in thread
* [PATCH 23/62] ARM: omap1: fix building without 32K_TIMER
@ 2014-03-21 16:01 ` Arnd Bergmann
0 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-21 16:01 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 19 March 2014, Tony Lindgren wrote:
> * Felipe Balbi <balbi@ti.com> [140319 13:06]:
> > On Wed, Mar 19, 2014 at 02:59:13PM -0500, Felipe Balbi wrote:
> > > I had sent a fix for months and months ago, what happened to it ?
> >
> > Here
> >
> > http://marc.info/?l=linux-omap&m=138963632408031&w=2
> >
> > Tony, did you forget to send a pull request ?
>
> Hmm yes weird, can't see it in my omap-for-v3.14/fixes branch.
>
> I must have gotten interrupted while applying and then probably
> ran git reset --hard before committing.
>
> Arnd, maybe pick up Felipe's earlier patch instead?
>
> Acked-by: Tony Lindgren <tony@atomide.com>
Ok, using this version now, thanks!
Arnd
>From 64cdcf550319a37d1419aa6a87903e67b9d3d031 Mon Sep 17 00:00:00 2001
From: Felipe Balbi <balbi@ti.com>
Date: Sun, 16 Mar 2014 17:57:55 +0100
Subject: [PATCH] ARM: omap1: fix build when !CONFIG_OMAP_32K_TIMER
If CONFIG_OMAP_32K_TIMER isn't enabled, we will
try to use enable_dyn_sleep which wasn't defined
anywhere.
In order to fix the problem, we always define
enable_dyn_sleep as 0 when !CONFIG_OMAP_32K_TIMER.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c
index 40a1ae3..dbee729 100644
--- a/arch/arm/mach-omap1/pm.c
+++ b/arch/arm/mach-omap1/pm.c
@@ -71,7 +71,11 @@ static unsigned int mpui7xx_sleep_save[MPUI7XX_SLEEP_SAVE_SIZE];
static unsigned int mpui1510_sleep_save[MPUI1510_SLEEP_SAVE_SIZE];
static unsigned int mpui1610_sleep_save[MPUI1610_SLEEP_SAVE_SIZE];
-#ifdef CONFIG_OMAP_32K_TIMER
+#ifndef CONFIG_OMAP_32K_TIMER
+
+static unsigned short enable_dyn_sleep = 0;
+
+#else
static unsigned short enable_dyn_sleep = 1;
^ permalink raw reply related [flat|nested] 205+ messages in thread
* [PATCH 24/62] ARM: omap1: select I2C where needed for PMIC
2014-03-19 19:28 ` Arnd Bergmann
@ 2014-03-19 19:29 ` Arnd Bergmann
-1 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: arm; +Cc: linux-arm-kernel, Arnd Bergmann, Tony Lindgren, linux-omap
The OMAP H2, OSK and OSIRIS machines cannot build without
I2C and TPS65010 both enabled unconditionally.
In each case, failing to enable CONFIG_I2C results in a
build or link error, so most consistent solution is to
ensure that it is impossible to disable those options.
It would be nice to leave CONFIG_I2C as user-selectable,
but doing that properly would require more work.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tony Lindgren <tony@atomide.com>
Cc: linux-omap@vger.kernel.org
---
arch/arm/mach-omap1/Kconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig
index cdd05f2..23ab1d5 100644
--- a/arch/arm/mach-omap1/Kconfig
+++ b/arch/arm/mach-omap1/Kconfig
@@ -44,6 +44,8 @@ config MACH_OMAP_INNOVATOR
config MACH_OMAP_H2
bool "TI H2 Support"
depends on ARCH_OMAP1 && ARCH_OMAP16XX
+ select TPS65010
+ select I2C
help
TI OMAP 1610/1611B H2 board support. Say Y here if you have such
a board.
@@ -64,6 +66,8 @@ config MACH_HERALD
config MACH_OMAP_OSK
bool "TI OSK Support"
depends on ARCH_OMAP1 && ARCH_OMAP16XX
+ select TPS65010
+ select I2C
help
TI OMAP 5912 OSK (OMAP Starter Kit) board support. Say Y here
if you have such a board.
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 24/62] ARM: omap1: select I2C where needed for PMIC
@ 2014-03-19 19:29 ` Arnd Bergmann
0 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
The OMAP H2, OSK and OSIRIS machines cannot build without
I2C and TPS65010 both enabled unconditionally.
In each case, failing to enable CONFIG_I2C results in a
build or link error, so most consistent solution is to
ensure that it is impossible to disable those options.
It would be nice to leave CONFIG_I2C as user-selectable,
but doing that properly would require more work.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tony Lindgren <tony@atomide.com>
Cc: linux-omap at vger.kernel.org
---
arch/arm/mach-omap1/Kconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig
index cdd05f2..23ab1d5 100644
--- a/arch/arm/mach-omap1/Kconfig
+++ b/arch/arm/mach-omap1/Kconfig
@@ -44,6 +44,8 @@ config MACH_OMAP_INNOVATOR
config MACH_OMAP_H2
bool "TI H2 Support"
depends on ARCH_OMAP1 && ARCH_OMAP16XX
+ select TPS65010
+ select I2C
help
TI OMAP 1610/1611B H2 board support. Say Y here if you have such
a board.
@@ -64,6 +66,8 @@ config MACH_HERALD
config MACH_OMAP_OSK
bool "TI OSK Support"
depends on ARCH_OMAP1 && ARCH_OMAP16XX
+ select TPS65010
+ select I2C
help
TI OMAP 5912 OSK (OMAP Starter Kit) board support. Say Y here
if you have such a board.
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* Re: [PATCH 24/62] ARM: omap1: select I2C where needed for PMIC
2014-03-19 19:29 ` Arnd Bergmann
@ 2014-03-19 20:46 ` Tony Lindgren
-1 siblings, 0 replies; 205+ messages in thread
From: Tony Lindgren @ 2014-03-19 20:46 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: arm, linux-arm-kernel, linux-omap
* Arnd Bergmann <arnd@arndb.de> [140319 12:33]:
> The OMAP H2, OSK and OSIRIS machines cannot build without
> I2C and TPS65010 both enabled unconditionally.
>
> In each case, failing to enable CONFIG_I2C results in a
> build or link error, so most consistent solution is to
> ensure that it is impossible to disable those options.
>
> It would be nice to leave CONFIG_I2C as user-selectable,
> but doing that properly would require more work.
We should not select drivers. How about let's just have
the tps65010 stuff behind an ifdef CONFIG_TPS65010 for
those boards?
Regards,
Tony
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: linux-omap@vger.kernel.org
> ---
> arch/arm/mach-omap1/Kconfig | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig
> index cdd05f2..23ab1d5 100644
> --- a/arch/arm/mach-omap1/Kconfig
> +++ b/arch/arm/mach-omap1/Kconfig
> @@ -44,6 +44,8 @@ config MACH_OMAP_INNOVATOR
> config MACH_OMAP_H2
> bool "TI H2 Support"
> depends on ARCH_OMAP1 && ARCH_OMAP16XX
> + select TPS65010
> + select I2C
> help
> TI OMAP 1610/1611B H2 board support. Say Y here if you have such
> a board.
> @@ -64,6 +66,8 @@ config MACH_HERALD
> config MACH_OMAP_OSK
> bool "TI OSK Support"
> depends on ARCH_OMAP1 && ARCH_OMAP16XX
> + select TPS65010
> + select I2C
> help
> TI OMAP 5912 OSK (OMAP Starter Kit) board support. Say Y here
> if you have such a board.
> --
> 1.8.3.2
>
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 24/62] ARM: omap1: select I2C where needed for PMIC
@ 2014-03-19 20:46 ` Tony Lindgren
0 siblings, 0 replies; 205+ messages in thread
From: Tony Lindgren @ 2014-03-19 20:46 UTC (permalink / raw)
To: linux-arm-kernel
* Arnd Bergmann <arnd@arndb.de> [140319 12:33]:
> The OMAP H2, OSK and OSIRIS machines cannot build without
> I2C and TPS65010 both enabled unconditionally.
>
> In each case, failing to enable CONFIG_I2C results in a
> build or link error, so most consistent solution is to
> ensure that it is impossible to disable those options.
>
> It would be nice to leave CONFIG_I2C as user-selectable,
> but doing that properly would require more work.
We should not select drivers. How about let's just have
the tps65010 stuff behind an ifdef CONFIG_TPS65010 for
those boards?
Regards,
Tony
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: linux-omap at vger.kernel.org
> ---
> arch/arm/mach-omap1/Kconfig | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig
> index cdd05f2..23ab1d5 100644
> --- a/arch/arm/mach-omap1/Kconfig
> +++ b/arch/arm/mach-omap1/Kconfig
> @@ -44,6 +44,8 @@ config MACH_OMAP_INNOVATOR
> config MACH_OMAP_H2
> bool "TI H2 Support"
> depends on ARCH_OMAP1 && ARCH_OMAP16XX
> + select TPS65010
> + select I2C
> help
> TI OMAP 1610/1611B H2 board support. Say Y here if you have such
> a board.
> @@ -64,6 +66,8 @@ config MACH_HERALD
> config MACH_OMAP_OSK
> bool "TI OSK Support"
> depends on ARCH_OMAP1 && ARCH_OMAP16XX
> + select TPS65010
> + select I2C
> help
> TI OMAP 5912 OSK (OMAP Starter Kit) board support. Say Y here
> if you have such a board.
> --
> 1.8.3.2
>
^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: [PATCH 24/62] ARM: omap1: select I2C where needed for PMIC
2014-03-19 20:46 ` Tony Lindgren
@ 2014-03-19 20:57 ` Arnd Bergmann
-1 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 20:57 UTC (permalink / raw)
To: Tony Lindgren; +Cc: arm, linux-arm-kernel, linux-omap
On Wednesday 19 March 2014 13:46:19 Tony Lindgren wrote:
> * Arnd Bergmann <arnd@arndb.de> [140319 12:33]:
> > The OMAP H2, OSK and OSIRIS machines cannot build without
> > I2C and TPS65010 both enabled unconditionally.
> >
> > In each case, failing to enable CONFIG_I2C results in a
> > build or link error, so most consistent solution is to
> > ensure that it is impossible to disable those options.
> >
> > It would be nice to leave CONFIG_I2C as user-selectable,
> > but doing that properly would require more work.
>
> We should not select drivers. How about let's just have
> the tps65010 stuff behind an ifdef CONFIG_TPS65010 for
> those boards?
Good idea. Like this?
Arnd
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index fd90caf..65d2acb 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -318,6 +318,9 @@ static void __init h2_init_smc91x(void)
static int tps_setup(struct i2c_client *client, void *context)
{
+ if (!IS_BUILTIN(CONFIG_TPS65010))
+ return -ENOSYS;
+
tps65010_config_vregs1(TPS_LDO2_ENABLE | TPS_VLDO2_3_0V |
TPS_LDO1_ENABLE | TPS_VLDO1_3_0V);
diff --git a/arch/arm/mach-omap1/board-osk.c b/arch/arm/mach-omap1/board-osk.c
index d68909b..3a02621 100644
--- a/arch/arm/mach-omap1/board-osk.c
+++ b/arch/arm/mach-omap1/board-osk.c
@@ -191,6 +191,9 @@ static struct platform_device osk5912_tps_leds = {
static int osk_tps_setup(struct i2c_client *client, void *context)
{
+ if (!IS_BUILTIN(CONFIG_TPS65010))
+ return -ENOSYS;
+
/* Set GPIO 1 HIGH to disable VBUS power supply;
* OHCI driver powers it up/down as needed.
*/
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 24/62] ARM: omap1: select I2C where needed for PMIC
@ 2014-03-19 20:57 ` Arnd Bergmann
0 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 20:57 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 19 March 2014 13:46:19 Tony Lindgren wrote:
> * Arnd Bergmann <arnd@arndb.de> [140319 12:33]:
> > The OMAP H2, OSK and OSIRIS machines cannot build without
> > I2C and TPS65010 both enabled unconditionally.
> >
> > In each case, failing to enable CONFIG_I2C results in a
> > build or link error, so most consistent solution is to
> > ensure that it is impossible to disable those options.
> >
> > It would be nice to leave CONFIG_I2C as user-selectable,
> > but doing that properly would require more work.
>
> We should not select drivers. How about let's just have
> the tps65010 stuff behind an ifdef CONFIG_TPS65010 for
> those boards?
Good idea. Like this?
Arnd
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index fd90caf..65d2acb 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -318,6 +318,9 @@ static void __init h2_init_smc91x(void)
static int tps_setup(struct i2c_client *client, void *context)
{
+ if (!IS_BUILTIN(CONFIG_TPS65010))
+ return -ENOSYS;
+
tps65010_config_vregs1(TPS_LDO2_ENABLE | TPS_VLDO2_3_0V |
TPS_LDO1_ENABLE | TPS_VLDO1_3_0V);
diff --git a/arch/arm/mach-omap1/board-osk.c b/arch/arm/mach-omap1/board-osk.c
index d68909b..3a02621 100644
--- a/arch/arm/mach-omap1/board-osk.c
+++ b/arch/arm/mach-omap1/board-osk.c
@@ -191,6 +191,9 @@ static struct platform_device osk5912_tps_leds = {
static int osk_tps_setup(struct i2c_client *client, void *context)
{
+ if (!IS_BUILTIN(CONFIG_TPS65010))
+ return -ENOSYS;
+
/* Set GPIO 1 HIGH to disable VBUS power supply;
* OHCI driver powers it up/down as needed.
*/
^ permalink raw reply related [flat|nested] 205+ messages in thread* Re: [PATCH 24/62] ARM: omap1: select I2C where needed for PMIC
2014-03-19 20:57 ` Arnd Bergmann
@ 2014-03-19 21:04 ` Tony Lindgren
-1 siblings, 0 replies; 205+ messages in thread
From: Tony Lindgren @ 2014-03-19 21:04 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: arm, linux-arm-kernel, linux-omap
* Arnd Bergmann <arnd@arndb.de> [140319 14:01]:
> On Wednesday 19 March 2014 13:46:19 Tony Lindgren wrote:
> > * Arnd Bergmann <arnd@arndb.de> [140319 12:33]:
> > > The OMAP H2, OSK and OSIRIS machines cannot build without
> > > I2C and TPS65010 both enabled unconditionally.
> > >
> > > In each case, failing to enable CONFIG_I2C results in a
> > > build or link error, so most consistent solution is to
> > > ensure that it is impossible to disable those options.
> > >
> > > It would be nice to leave CONFIG_I2C as user-selectable,
> > > but doing that properly would require more work.
> >
> > We should not select drivers. How about let's just have
> > the tps65010 stuff behind an ifdef CONFIG_TPS65010 for
> > those boards?
>
> Good idea. Like this?
Looks good to me :)
Acked-by: Tony Lindgren <tony@atomide.com>
> diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
> index fd90caf..65d2acb 100644
> --- a/arch/arm/mach-omap1/board-h2.c
> +++ b/arch/arm/mach-omap1/board-h2.c
> @@ -318,6 +318,9 @@ static void __init h2_init_smc91x(void)
>
> static int tps_setup(struct i2c_client *client, void *context)
> {
> + if (!IS_BUILTIN(CONFIG_TPS65010))
> + return -ENOSYS;
> +
> tps65010_config_vregs1(TPS_LDO2_ENABLE | TPS_VLDO2_3_0V |
> TPS_LDO1_ENABLE | TPS_VLDO1_3_0V);
>
> diff --git a/arch/arm/mach-omap1/board-osk.c b/arch/arm/mach-omap1/board-osk.c
> index d68909b..3a02621 100644
> --- a/arch/arm/mach-omap1/board-osk.c
> +++ b/arch/arm/mach-omap1/board-osk.c
> @@ -191,6 +191,9 @@ static struct platform_device osk5912_tps_leds = {
>
> static int osk_tps_setup(struct i2c_client *client, void *context)
> {
> + if (!IS_BUILTIN(CONFIG_TPS65010))
> + return -ENOSYS;
> +
> /* Set GPIO 1 HIGH to disable VBUS power supply;
> * OHCI driver powers it up/down as needed.
> */
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 205+ messages in thread* [PATCH 24/62] ARM: omap1: select I2C where needed for PMIC
@ 2014-03-19 21:04 ` Tony Lindgren
0 siblings, 0 replies; 205+ messages in thread
From: Tony Lindgren @ 2014-03-19 21:04 UTC (permalink / raw)
To: linux-arm-kernel
* Arnd Bergmann <arnd@arndb.de> [140319 14:01]:
> On Wednesday 19 March 2014 13:46:19 Tony Lindgren wrote:
> > * Arnd Bergmann <arnd@arndb.de> [140319 12:33]:
> > > The OMAP H2, OSK and OSIRIS machines cannot build without
> > > I2C and TPS65010 both enabled unconditionally.
> > >
> > > In each case, failing to enable CONFIG_I2C results in a
> > > build or link error, so most consistent solution is to
> > > ensure that it is impossible to disable those options.
> > >
> > > It would be nice to leave CONFIG_I2C as user-selectable,
> > > but doing that properly would require more work.
> >
> > We should not select drivers. How about let's just have
> > the tps65010 stuff behind an ifdef CONFIG_TPS65010 for
> > those boards?
>
> Good idea. Like this?
Looks good to me :)
Acked-by: Tony Lindgren <tony@atomide.com>
> diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
> index fd90caf..65d2acb 100644
> --- a/arch/arm/mach-omap1/board-h2.c
> +++ b/arch/arm/mach-omap1/board-h2.c
> @@ -318,6 +318,9 @@ static void __init h2_init_smc91x(void)
>
> static int tps_setup(struct i2c_client *client, void *context)
> {
> + if (!IS_BUILTIN(CONFIG_TPS65010))
> + return -ENOSYS;
> +
> tps65010_config_vregs1(TPS_LDO2_ENABLE | TPS_VLDO2_3_0V |
> TPS_LDO1_ENABLE | TPS_VLDO1_3_0V);
>
> diff --git a/arch/arm/mach-omap1/board-osk.c b/arch/arm/mach-omap1/board-osk.c
> index d68909b..3a02621 100644
> --- a/arch/arm/mach-omap1/board-osk.c
> +++ b/arch/arm/mach-omap1/board-osk.c
> @@ -191,6 +191,9 @@ static struct platform_device osk5912_tps_leds = {
>
> static int osk_tps_setup(struct i2c_client *client, void *context)
> {
> + if (!IS_BUILTIN(CONFIG_TPS65010))
> + return -ENOSYS;
> +
> /* Set GPIO 1 HIGH to disable VBUS power supply;
> * OHCI driver powers it up/down as needed.
> */
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 25/62] ARM: mvebu: add missing header
2014-03-19 19:28 ` Arnd Bergmann
` (24 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-19 19:34 ` Jason Cooper
2014-03-19 20:37 ` Gregory CLEMENT
-1 siblings, 2 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
The definition for SIGBUS may not be visible without including
linux/signal.h, as I found during randconfig testing.
Adding an explicit include is certainly the right thing to do.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
arch/arm/mach-mvebu/board-v7.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c
index 746134e..333fca8 100644
--- a/arch/arm/mach-mvebu/board-v7.c
+++ b/arch/arm/mach-mvebu/board-v7.c
@@ -21,6 +21,7 @@
#include <linux/clocksource.h>
#include <linux/dma-mapping.h>
#include <linux/mbus.h>
+#include <linux/signal.h>
#include <linux/slab.h>
#include <asm/hardware/cache-l2x0.h>
#include <asm/mach/arch.h>
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 25/62] ARM: mvebu: add missing header
2014-03-19 19:29 ` [PATCH 25/62] ARM: mvebu: add missing header Arnd Bergmann
@ 2014-03-19 19:34 ` Jason Cooper
2014-03-19 20:37 ` Gregory CLEMENT
1 sibling, 0 replies; 205+ messages in thread
From: Jason Cooper @ 2014-03-19 19:34 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Mar 19, 2014 at 08:29:22PM +0100, Arnd Bergmann wrote:
> The definition for SIGBUS may not be visible without including
> linux/signal.h, as I found during randconfig testing.
>
> Adding an explicit include is certainly the right thing to do.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Gregory Clement <gregory.clement@free-electrons.com>
> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> ---
> arch/arm/mach-mvebu/board-v7.c | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Jason Cooper <jason@lakedaemon.net>
thx,
Jason.
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 25/62] ARM: mvebu: add missing header
2014-03-19 19:29 ` [PATCH 25/62] ARM: mvebu: add missing header Arnd Bergmann
2014-03-19 19:34 ` Jason Cooper
@ 2014-03-19 20:37 ` Gregory CLEMENT
1 sibling, 0 replies; 205+ messages in thread
From: Gregory CLEMENT @ 2014-03-19 20:37 UTC (permalink / raw)
To: linux-arm-kernel
On 19/03/2014 20:29, Arnd Bergmann wrote:
> The definition for SIGBUS may not be visible without including
> linux/signal.h, as I found during randconfig testing.
>
> Adding an explicit include is certainly the right thing to do.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Gregory Clement <gregory.clement@free-electrons.com>
> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Thanks,
Gregory
> ---
> arch/arm/mach-mvebu/board-v7.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c
> index 746134e..333fca8 100644
> --- a/arch/arm/mach-mvebu/board-v7.c
> +++ b/arch/arm/mach-mvebu/board-v7.c
> @@ -21,6 +21,7 @@
> #include <linux/clocksource.h>
> #include <linux/dma-mapping.h>
> #include <linux/mbus.h>
> +#include <linux/signal.h>
> #include <linux/slab.h>
> #include <asm/hardware/cache-l2x0.h>
> #include <asm/mach/arch.h>
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 26/62] ARM: mvebu: don't select CONFIG_NEON
2014-03-19 19:28 ` Arnd Bergmann
` (25 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-19 19:37 ` Jason Cooper
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
CONFIG_NEON is meant to be user-selectable. Turning it on
unconditionally means we can't build a smaller kernel when
we don't need it, and causes build errors if CONFIG_VFP
is not also enabled.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
arch/arm/mach-mvebu/Kconfig | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 485513cb..b24a082 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -39,7 +39,6 @@ config MACH_ARMADA_375
select ARMADA_375_CLK
select CPU_V7
select MACH_MVEBU_V7
- select NEON
select PINCTRL_ARMADA_375
help
Say 'Y' here if you want your kernel to support boards based
@@ -53,7 +52,6 @@ config MACH_ARMADA_38X
select ARMADA_38X_CLK
select CPU_V7
select MACH_MVEBU_V7
- select NEON
select PINCTRL_ARMADA_38X
help
Say 'Y' here if you want your kernel to support boards based
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 26/62] ARM: mvebu: don't select CONFIG_NEON
2014-03-19 19:29 ` [PATCH 26/62] ARM: mvebu: don't select CONFIG_NEON Arnd Bergmann
@ 2014-03-19 19:37 ` Jason Cooper
2014-03-19 21:33 ` Gregory CLEMENT
0 siblings, 1 reply; 205+ messages in thread
From: Jason Cooper @ 2014-03-19 19:37 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Mar 19, 2014 at 08:29:23PM +0100, Arnd Bergmann wrote:
> CONFIG_NEON is meant to be user-selectable. Turning it on
> unconditionally means we can't build a smaller kernel when
> we don't need it, and causes build errors if CONFIG_VFP
> is not also enabled.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Gregory Clement <gregory.clement@free-electrons.com>
> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> ---
> arch/arm/mach-mvebu/Kconfig | 2 --
> 1 file changed, 2 deletions(-)
Acked-by: Jason Cooper <jason@lakedaemon.net>
Gregory, Thomas, Ezequiel,
Care to spin a patch adding NEON to mvebu_v7_defconfig? (If you want
it)
thx,
Jason.
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 26/62] ARM: mvebu: don't select CONFIG_NEON
2014-03-19 19:37 ` Jason Cooper
@ 2014-03-19 21:33 ` Gregory CLEMENT
2014-03-21 16:08 ` Arnd Bergmann
0 siblings, 1 reply; 205+ messages in thread
From: Gregory CLEMENT @ 2014-03-19 21:33 UTC (permalink / raw)
To: linux-arm-kernel
On 19/03/2014 20:37, Jason Cooper wrote:
> On Wed, Mar 19, 2014 at 08:29:23PM +0100, Arnd Bergmann wrote:
>> CONFIG_NEON is meant to be user-selectable. Turning it on
>> unconditionally means we can't build a smaller kernel when
>> we don't need it, and causes build errors if CONFIG_VFP
>> is not also enabled.
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> Cc: Jason Cooper <jason@lakedaemon.net>
>> Cc: Andrew Lunn <andrew@lunn.ch>
>> Cc: Gregory Clement <gregory.clement@free-electrons.com>
>> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
>> ---
>> arch/arm/mach-mvebu/Kconfig | 2 --
>> 1 file changed, 2 deletions(-)
>
> Acked-by: Jason Cooper <jason@lakedaemon.net>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>
> Gregory, Thomas, Ezequiel,
>
> Care to spin a patch adding NEON to mvebu_v7_defconfig? (If you want
> it)
I will send a patch in a couple of minute. I'd like that it was applied
on the same release that this patch if possible.
Thanks,
Gregory
>
> thx,
>
> Jason.
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 26/62] ARM: mvebu: don't select CONFIG_NEON
2014-03-19 21:33 ` Gregory CLEMENT
@ 2014-03-21 16:08 ` Arnd Bergmann
0 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-21 16:08 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 19 March 2014, Gregory CLEMENT wrote:
> On 19/03/2014 20:37, Jason Cooper wrote:
> > On Wed, Mar 19, 2014 at 08:29:23PM +0100, Arnd Bergmann wrote:
> >> CONFIG_NEON is meant to be user-selectable. Turning it on
> >> unconditionally means we can't build a smaller kernel when
> >> we don't need it, and causes build errors if CONFIG_VFP
> >> is not also enabled.
> >>
> >> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> >> Cc: Jason Cooper <jason@lakedaemon.net>
> >> Cc: Andrew Lunn <andrew@lunn.ch>
> >> Cc: Gregory Clement <gregory.clement@free-electrons.com>
> >> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> >> ---
> >> arch/arm/mach-mvebu/Kconfig | 2 --
> >> 1 file changed, 2 deletions(-)
> >
> > Acked-by: Jason Cooper <jason@lakedaemon.net>
>
>
> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Thanks! Here is my new version.
Arnd
>From 59532706506c0b3bf9f46499e7ba6c0f169e3802 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Mon, 24 Feb 2014 21:56:19 +0100
Subject: [PATCH] ARM: mvebu: don't select CONFIG_NEON
CONFIG_NEON is meant to be user-selectable. Turning it on
unconditionally means we can't build a smaller kernel when
we don't need it, and causes build errors if CONFIG_VFP
is not also enabled.
To still have neon enabled however, we need to turn it on
now in multi_v7_defconfig and mvebu_v7_defconfig.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Acked-by: Gregory Clement <gregory.clement@free-electrons.com>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 9ee12b5..cd16989 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -63,6 +63,7 @@ CONFIG_ARCH_VEXPRESS_CA9X4=y
CONFIG_ARCH_VIRT=y
CONFIG_ARCH_WM8850=y
CONFIG_ARCH_ZYNQ=y
+CONFIG_NEON=y
CONFIG_TRUSTED_FOUNDATIONS=y
CONFIG_PCI=y
CONFIG_PCI_MSI=y
diff --git a/arch/arm/configs/mvebu_v7_defconfig b/arch/arm/configs/mvebu_v7_defconfig
index 62b6a37..a34713d 100644
--- a/arch/arm/configs/mvebu_v7_defconfig
+++ b/arch/arm/configs/mvebu_v7_defconfig
@@ -13,6 +13,7 @@ CONFIG_MACH_ARMADA_370=y
CONFIG_MACH_ARMADA_375=y
CONFIG_MACH_ARMADA_38X=y
CONFIG_MACH_ARMADA_XP=y
+CONFIG_NEON=y
# CONFIG_CACHE_L2X0 is not set
# CONFIG_SWP_EMULATE is not set
CONFIG_PCI=y
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 485513cb..b24a082 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -39,7 +39,6 @@ config MACH_ARMADA_375
select ARMADA_375_CLK
select CPU_V7
select MACH_MVEBU_V7
- select NEON
select PINCTRL_ARMADA_375
help
Say 'Y' here if you want your kernel to support boards based
@@ -53,7 +52,6 @@ config MACH_ARMADA_38X
select ARMADA_38X_CLK
select CPU_V7
select MACH_MVEBU_V7
- select NEON
select PINCTRL_ARMADA_38X
help
Say 'Y' here if you want your kernel to support boards based
^ permalink raw reply related [flat|nested] 205+ messages in thread
* [PATCH 27/62] ARM: orion5x: make dns323 independent of PHY support
2014-03-19 19:28 ` Arnd Bergmann
` (26 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-19 19:39 ` Jason Cooper
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
The D-Link DNS-323 machine tries to unconditionally select CONFIG_PHYLIB,
but that has other dependencies that might not necessarily be enabled,
causing random build errors.
To work around this, this patch removes the 'select' statement and
instead uses a compile-time check to skip the phy_register_fixup_for_uid()
call if PHYLIB is not available in the kernel.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
arch/arm/mach-orion5x/Kconfig | 1 -
arch/arm/mach-orion5x/dns323-setup.c | 2 ++
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-orion5x/Kconfig b/arch/arm/mach-orion5x/Kconfig
index 2cb2f06..14f2cae 100644
--- a/arch/arm/mach-orion5x/Kconfig
+++ b/arch/arm/mach-orion5x/Kconfig
@@ -33,7 +33,6 @@ config MACH_KUROBOX_PRO
config MACH_DNS323
bool "D-Link DNS-323"
select I2C_BOARDINFO
- select PHYLIB
help
Say 'Y' here if you want your kernel to support the
D-Link DNS-323 platform.
diff --git a/arch/arm/mach-orion5x/dns323-setup.c b/arch/arm/mach-orion5x/dns323-setup.c
index 7097473..56edeab 100644
--- a/arch/arm/mach-orion5x/dns323-setup.c
+++ b/arch/arm/mach-orion5x/dns323-setup.c
@@ -642,6 +642,8 @@ static void __init dns323_init(void)
platform_device_register_simple("dns323c-fan", 0, NULL, 0);
/* Register fixup for the PHY LEDs */
+ if (!IS_BUILTIN(CONFIG_PHYLIB))
+ break;
phy_register_fixup_for_uid(MARVELL_PHY_ID_88E1118,
MARVELL_PHY_ID_MASK,
dns323c_phy_fixup);
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 27/62] ARM: orion5x: make dns323 independent of PHY support
2014-03-19 19:29 ` [PATCH 27/62] ARM: orion5x: make dns323 independent of PHY support Arnd Bergmann
@ 2014-03-19 19:39 ` Jason Cooper
0 siblings, 0 replies; 205+ messages in thread
From: Jason Cooper @ 2014-03-19 19:39 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Mar 19, 2014 at 08:29:24PM +0100, Arnd Bergmann wrote:
> The D-Link DNS-323 machine tries to unconditionally select CONFIG_PHYLIB,
> but that has other dependencies that might not necessarily be enabled,
> causing random build errors.
>
> To work around this, this patch removes the 'select' statement and
> instead uses a compile-time check to skip the phy_register_fixup_for_uid()
> call if PHYLIB is not available in the kernel.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Gregory Clement <gregory.clement@free-electrons.com>
> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> ---
> arch/arm/mach-orion5x/Kconfig | 1 -
> arch/arm/mach-orion5x/dns323-setup.c | 2 ++
> 2 files changed, 2 insertions(+), 1 deletion(-)
Acked-by: Jason Cooper <jason@lakedaemon.net>
thx,
Jason.
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 28/62] ARM: pxa: FB_W100 must be built-in
2014-03-19 19:28 ` Arnd Bergmann
` (27 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-21 16:28 ` Arnd Bergmann
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
The pxa platform code directly calls into the W100 framebuffer
driver for eseries. This means it cannot be a loadable module
and we also have to ensure that the core framebuffer code
is built-in.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Daniel Mack <zonque@gmail.com>
---
arch/arm/mach-pxa/Kconfig | 1 +
drivers/video/Kconfig | 4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
index 96100db..562b17f 100644
--- a/arch/arm/mach-pxa/Kconfig
+++ b/arch/arm/mach-pxa/Kconfig
@@ -556,6 +556,7 @@ config MACH_ICONTROL
config ARCH_PXA_ESERIES
bool "PXA based Toshiba e-series PDAs"
select FB_W100
+ select FB
select PXA25x
config MACH_E330
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index dade5b7..86873ff 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -1996,8 +1996,8 @@ config FB_FSL_DIU
Framebuffer driver for the Freescale SoC DIU
config FB_W100
- tristate "W100 frame buffer support"
- depends on FB && ARCH_PXA
+ bool "W100 frame buffer support"
+ depends on FB=y && ARCH_PXA
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 28/62] ARM: pxa: FB_W100 must be built-in
2014-03-19 19:29 ` [PATCH 28/62] ARM: pxa: FB_W100 must be built-in Arnd Bergmann
@ 2014-03-21 16:28 ` Arnd Bergmann
0 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-21 16:28 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 19 March 2014, Arnd Bergmann wrote:
> The pxa platform code directly calls into the W100 framebuffer
> driver for eseries. This means it cannot be a loadable module
> and we also have to ensure that the core framebuffer code
> is built-in.
>
Ignore this once, I'll drop it from the series and do a proper
fix, like we did for some of the other patches. It's better
to change the code not to call into the fb driver if that is
disabled.
Arnd
> diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
> index 96100db..562b17f 100644
> --- a/arch/arm/mach-pxa/Kconfig
> +++ b/arch/arm/mach-pxa/Kconfig
> @@ -556,6 +556,7 @@ config MACH_ICONTROL
> config ARCH_PXA_ESERIES
> bool "PXA based Toshiba e-series PDAs"
> select FB_W100
> + select FB
> select PXA25x
>
> config MACH_E330
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index dade5b7..86873ff 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -1996,8 +1996,8 @@ config FB_FSL_DIU
> Framebuffer driver for the Freescale SoC DIU
>
> config FB_W100
> - tristate "W100 frame buffer support"
> - depends on FB && ARCH_PXA
> + bool "W100 frame buffer support"
> + depends on FB=y && ARCH_PXA
> select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
> --
> 1.8.3.2
>
>
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 29/62] ARM: pxa: don't "select" SMC91X on MACH_XCEP
2014-03-19 19:28 ` Arnd Bergmann
` (28 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
-1 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
We normally don't hard-enable Kconfig options just because
a board contains a specific piece of hardware. In this case,
selecting SMC91X causes a build error, if we don't also enable
basic network device driver support.
Since the platform has no direct dependency on this driver
at link time, we can just remove the 'select' statement.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Daniel Mack <zonque@gmail.com>
---
arch/arm/mach-pxa/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
index 562b17f..2c7498a 100644
--- a/arch/arm/mach-pxa/Kconfig
+++ b/arch/arm/mach-pxa/Kconfig
@@ -164,7 +164,6 @@ config MACH_XCEP
select MTD_CFI_INTELEXT
select MTD_PHYSMAP
select PXA25x
- select SMC91X
help
PXA255 based Single Board Computer with SMC 91C111 ethernet chip and 64 MB of flash.
Tuned for usage in Libera instruments for particle accelerators.
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 30/62] ARM: pxa: enable pxafb unconditionally for some boards
2014-03-19 19:28 ` Arnd Bergmann
` (29 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
-1 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
The SAAR and TAVOREVB machines try to call functions from
the PXAFB frame buffer driver from their platform code,
which only works if that driver is built-in.
This patch ensures that both the generic frame buffer
code and the specific pxafb driver are always enabled
when we build a kernel for one of the two boards.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Daniel Mack <zonque@gmail.com>
---
arch/arm/mach-pxa/Kconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
index 2c7498a..50f6132 100644
--- a/arch/arm/mach-pxa/Kconfig
+++ b/arch/arm/mach-pxa/Kconfig
@@ -53,12 +53,16 @@ config MACH_TAVOREVB
select CPU_PXA930
select CPU_PXA935
select PXA3xx
+ select FB
+ select FB_PXA
config MACH_SAAR
bool "PXA930 Handheld Platform (aka SAAR)"
select CPU_PXA930
select CPU_PXA935
select PXA3xx
+ select FB
+ select FB_PXA
comment "Third Party Dev Platforms (sorted by vendor name)"
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 31/62] ARM: pxa: fix colibri build
2014-03-19 19:28 ` Arnd Bergmann
` (30 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
-1 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
The colibri_ohci_init function performs a register access through
the io_p2v() macro, which requires the IOMEM macro to be defined.
By explicitly including the asm/io.h header file that contains
this macro, we avoid the build error:
arch/arm/mach-pxa/colibri-evalboard.c: In function 'colibri_ohci_init':
arch/arm/mach-pxa/colibri-evalboard.c:68:2: error: implicit declaration of function 'IOMEM' [-Werror=implicit-function-declaration]
UP2OCR = UP2OCR_HXS | UP2OCR_HXOE | UP2OCR_DPPDE | UP2OCR_DMPDE;
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Daniel Mack <zonque@gmail.com>
---
arch/arm/mach-pxa/colibri-evalboard.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-pxa/colibri-evalboard.c b/arch/arm/mach-pxa/colibri-evalboard.c
index 8404b24..638b0bb 100644
--- a/arch/arm/mach-pxa/colibri-evalboard.c
+++ b/arch/arm/mach-pxa/colibri-evalboard.c
@@ -20,6 +20,7 @@
#include <asm/mach/arch.h>
#include <linux/i2c.h>
#include <linux/i2c/pxa-i2c.h>
+#include <asm/io.h>
#include <mach/pxa27x.h>
#include <mach/colibri.h>
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 32/62] ARM: pxa: fix pxa_ssp_* declarations
2014-03-19 19:28 ` Arnd Bergmann
` (31 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
-1 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
The functions declared in include/linux/pxa2xx_ssp.h are
defined in plat-pxa/ssp.c, which can also be built for
PLAT_MMP, but may be disabled there. This can lead to
both unresolved symbols at link time and to duplicate
symbols at compile time for random configurations.
Changing the #ifdef in the header file to match the
Kconfig symbol that decides if the file is built solves
both problems.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Daniel Mack <zonque@gmail.com>
---
include/linux/pxa2xx_ssp.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/pxa2xx_ssp.h b/include/linux/pxa2xx_ssp.h
index 4944420..f2b4051 100644
--- a/include/linux/pxa2xx_ssp.h
+++ b/include/linux/pxa2xx_ssp.h
@@ -219,7 +219,7 @@ static inline u32 pxa_ssp_read_reg(struct ssp_device *dev, u32 reg)
return __raw_readl(dev->mmio_base + reg);
}
-#ifdef CONFIG_ARCH_PXA
+#if IS_ENABLED(CONFIG_PXA_SSP)
struct ssp_device *pxa_ssp_request(int port, const char *label);
void pxa_ssp_free(struct ssp_device *);
struct ssp_device *pxa_ssp_request_of(const struct device_node *of_node,
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 33/62] ARM: pxa: remove broken balloon3_gpio_vbus reference
2014-03-19 19:28 ` Arnd Bergmann
` (32 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
-1 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
balloon3_udc_init() tries to register a balloon3_gpio_vbus
device, but this has never been defined in the mainline
kernel. To avoid the obvious build failure when this function
is enabled, remove the bogus reference here.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Daniel Mack <zonque@gmail.com>
---
arch/arm/mach-pxa/balloon3.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-pxa/balloon3.c b/arch/arm/mach-pxa/balloon3.c
index 2f71b3f..43596e0 100644
--- a/arch/arm/mach-pxa/balloon3.c
+++ b/arch/arm/mach-pxa/balloon3.c
@@ -331,7 +331,6 @@ static struct pxa2xx_udc_mach_info balloon3_udc_info __initdata = {
static void __init balloon3_udc_init(void)
{
pxa_set_udc_info(&balloon3_udc_info);
- platform_device_register(&balloon3_gpio_vbus);
}
#else
static inline void balloon3_udc_init(void) {}
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 34/62] ARM: pxa: select I2C_GPIO only if I2C is on
2014-03-19 19:28 ` Arnd Bergmann
` (33 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-20 1:51 ` Haojian Zhuang
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
The Arcom/Eurotech VIPER SBC enables the I2C_GPIO driver, but
that has a dependency on I2C, and causes build failures if I2C
is disabled. To keep existing configurations running while fixing
the randconfig problems, this changes the logic to only enable
I2C_GPIO if I2C is already enabled.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Daniel Mack <zonque@gmail.com>
---
arch/arm/mach-pxa/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
index 50f6132..8d9f4f1 100644
--- a/arch/arm/mach-pxa/Kconfig
+++ b/arch/arm/mach-pxa/Kconfig
@@ -73,8 +73,7 @@ config ARCH_PXA_IDP
config ARCH_VIPER
bool "Arcom/Eurotech VIPER SBC"
select ARCOM_PCMCIA
- select HAVE_PWM
- select I2C_GPIO
+ select I2C_GPIO if I2C=y
select ISA
select PXA25x
select PXA_HAVE_ISA_IRQS
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 34/62] ARM: pxa: select I2C_GPIO only if I2C is on
2014-03-19 19:29 ` [PATCH 34/62] ARM: pxa: select I2C_GPIO only if I2C is on Arnd Bergmann
@ 2014-03-20 1:51 ` Haojian Zhuang
0 siblings, 0 replies; 205+ messages in thread
From: Haojian Zhuang @ 2014-03-20 1:51 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Mar 20, 2014 at 3:29 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> The Arcom/Eurotech VIPER SBC enables the I2C_GPIO driver, but
> that has a dependency on I2C, and causes build failures if I2C
> is disabled. To keep existing configurations running while fixing
> the randconfig problems, this changes the logic to only enable
> I2C_GPIO if I2C is already enabled.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Eric Miao <eric.y.miao@gmail.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
> Cc: Daniel Mack <zonque@gmail.com>
> ---
> arch/arm/mach-pxa/Kconfig | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
> index 50f6132..8d9f4f1 100644
> --- a/arch/arm/mach-pxa/Kconfig
> +++ b/arch/arm/mach-pxa/Kconfig
> @@ -73,8 +73,7 @@ config ARCH_PXA_IDP
> config ARCH_VIPER
> bool "Arcom/Eurotech VIPER SBC"
> select ARCOM_PCMCIA
> - select HAVE_PWM
> - select I2C_GPIO
> + select I2C_GPIO if I2C=y
> select ISA
> select PXA25x
> select PXA_HAVE_ISA_IRQS
> --
> 1.8.3.2
>
Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 35/62] ARM: pxa: trizeps4 and trizeps4wl use the same file
2014-03-19 19:28 ` Arnd Bergmann
` (34 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
-1 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
The trizeps4 and trizeps4wl platforms are both implemented
using the same board file. Since the trizeps4wl code is a
superset of trizeps4, it makes no sense to enable just the
latter, but with the current Kconfig logic, it causes the
board file not to be built at all.
Selecting MACH_TRIZEPS4 from MACH_TRIZEPS4WL ensures that
we are actually building the board file.
Found during randconfig testing.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Daniel Mack <zonque@gmail.com>
---
arch/arm/mach-pxa/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
index 8d9f4f1..692aa5c 100644
--- a/arch/arm/mach-pxa/Kconfig
+++ b/arch/arm/mach-pxa/Kconfig
@@ -183,6 +183,7 @@ config MACH_TRIZEPS4
config MACH_TRIZEPS4WL
bool "Keith und Koep Trizeps4-WL DIMM-Module"
depends on TRIZEPS_PXA
+ select MACH_TRIZEPS4
select PXA27x
select TRIZEPS_PCMCIA
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 36/62] ARM: rpc: autoselect CPU_SA110
2014-03-19 19:28 ` Arnd Bergmann
` (35 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
-1 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
ARCH_RPC no longer supports other CPUs aside from StrongARM110,
so we can make the option implicitly selected by the platform
and no longer give the option of building a kernel without CPU
support.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>
---
arch/arm/Kconfig | 1 +
arch/arm/mm/Kconfig | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5776c12..4721007 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -696,6 +696,7 @@ config ARCH_RPC
select ARCH_MAY_HAVE_PC_FDC
select ARCH_SPARSEMEM_ENABLE
select ARCH_USES_GETTIMEOFFSET
+ select CPU_SA110
select FIQ
select HAVE_IDE
select HAVE_PATA_PLATFORM
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index dccd7e1..297b63b 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -264,7 +264,7 @@ config CPU_ARM1026
# SA110
config CPU_SA110
- bool "Support StrongARM(R) SA-110 processor" if ARCH_RPC
+ bool
select CPU_32v3 if ARCH_RPC
select CPU_32v4 if !ARCH_RPC
select CPU_ABRT_EV4
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 37/62] ARM: sa1100/pxa: fix MTD_XIP build
2014-03-19 19:28 ` Arnd Bergmann
` (36 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-19 20:12 ` Russell King - ARM Linux
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
In commit 3169663ac5902 "ARM: sa11x0/pxa: convert OS timer registers
to IOMEM", the definition of the OSCR macro was changed to be an
__iomem pointer, but the same register is also used by the XIP
code. This patch does the corresponding change here as well.
Since PXA now uses a local variable for the base address of the
ICIP register, the xip_irqpending function has to be moved
into irq.c in the process.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>
---
arch/arm/mach-pxa/include/mach/mtd-xip.h | 7 ++++---
arch/arm/mach-pxa/irq.c | 8 ++++++++
arch/arm/mach-sa1100/include/mach/mtd-xip.h | 4 ++--
3 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-pxa/include/mach/mtd-xip.h b/arch/arm/mach-pxa/include/mach/mtd-xip.h
index 990d2bf..c4c90d1 100644
--- a/arch/arm/mach-pxa/include/mach/mtd-xip.h
+++ b/arch/arm/mach-pxa/include/mach/mtd-xip.h
@@ -17,11 +17,12 @@
#include <mach/regs-ost.h>
-#define xip_irqpending() (ICIP & ICMR)
+extern bool xip_irqpending(void);
/* we sample OSCR and convert desired delta to usec (1/4 ~= 1000000/3686400) */
-#define xip_currtime() (OSCR)
-#define xip_elapsed_since(x) (signed)((OSCR - (x)) / 4)
+#define xip_irqpending() xip_irqpending()
+#define xip_currtime() readl(OSCR)
+#define xip_elapsed_since(x) (signed)((readl(OSCR) - (x)) / 4)
/*
* xip_cpu_idle() is used when waiting for a delay equal or larger than
diff --git a/arch/arm/mach-pxa/irq.c b/arch/arm/mach-pxa/irq.c
index 0eecd83..dcc8522 100644
--- a/arch/arm/mach-pxa/irq.c
+++ b/arch/arm/mach-pxa/irq.c
@@ -81,6 +81,14 @@ void pxa_unmask_irq(struct irq_data *d)
__raw_writel(icmr, base + ICMR);
}
+#ifdef CONFIG_MTD_XIP
+bool xip_irqpending(void)
+{
+ return readl(pxa_irq_base + ICIP) & readl(pxa_irq_base + ICMR);
+}
+EXPORT_SYMBOL_GPL(xip_irqpending);
+#endif
+
static struct irq_chip pxa_internal_irq_chip = {
.name = "SC",
.irq_ack = pxa_mask_irq,
diff --git a/arch/arm/mach-sa1100/include/mach/mtd-xip.h b/arch/arm/mach-sa1100/include/mach/mtd-xip.h
index b3d6840..cb76096 100644
--- a/arch/arm/mach-sa1100/include/mach/mtd-xip.h
+++ b/arch/arm/mach-sa1100/include/mach/mtd-xip.h
@@ -20,7 +20,7 @@
#define xip_irqpending() (ICIP & ICMR)
/* we sample OSCR and convert desired delta to usec (1/4 ~= 1000000/3686400) */
-#define xip_currtime() (OSCR)
-#define xip_elapsed_since(x) (signed)((OSCR - (x)) / 4)
+#define xip_currtime() readl_relaxed(OSCR)
+#define xip_elapsed_since(x) (signed)((readl_relaxed(OSCR) - (x)) / 4)
#endif /* __ARCH_SA1100_MTD_XIP_H__ */
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 37/62] ARM: sa1100/pxa: fix MTD_XIP build
2014-03-19 19:29 ` [PATCH 37/62] ARM: sa1100/pxa: fix MTD_XIP build Arnd Bergmann
@ 2014-03-19 20:12 ` Russell King - ARM Linux
2014-03-19 22:00 ` Nicolas Pitre
2014-03-21 16:11 ` Arnd Bergmann
0 siblings, 2 replies; 205+ messages in thread
From: Russell King - ARM Linux @ 2014-03-19 20:12 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Mar 19, 2014 at 08:29:34PM +0100, Arnd Bergmann wrote:
> In commit 3169663ac5902 "ARM: sa11x0/pxa: convert OS timer registers
> to IOMEM", the definition of the OSCR macro was changed to be an
> __iomem pointer, but the same register is also used by the XIP
> code. This patch does the corresponding change here as well.
>
> Since PXA now uses a local variable for the base address of the
> ICIP register, the xip_irqpending function has to be moved
> into irq.c in the process.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Russell King <linux@arm.linux.org.uk>
> ---
> arch/arm/mach-pxa/include/mach/mtd-xip.h | 7 ++++---
> arch/arm/mach-pxa/irq.c | 8 ++++++++
> arch/arm/mach-sa1100/include/mach/mtd-xip.h | 4 ++--
> 3 files changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/include/mach/mtd-xip.h b/arch/arm/mach-pxa/include/mach/mtd-xip.h
> index 990d2bf..c4c90d1 100644
> --- a/arch/arm/mach-pxa/include/mach/mtd-xip.h
> +++ b/arch/arm/mach-pxa/include/mach/mtd-xip.h
> @@ -17,11 +17,12 @@
>
> #include <mach/regs-ost.h>
>
> -#define xip_irqpending() (ICIP & ICMR)
> +extern bool xip_irqpending(void);
>
> /* we sample OSCR and convert desired delta to usec (1/4 ~= 1000000/3686400) */
> -#define xip_currtime() (OSCR)
> -#define xip_elapsed_since(x) (signed)((OSCR - (x)) / 4)
> +#define xip_irqpending() xip_irqpending()
> +#define xip_currtime() readl(OSCR)
> +#define xip_elapsed_since(x) (signed)((readl(OSCR) - (x)) / 4)
I don't think you can do that. I believe xip_irqpending() has to be
inline so that the XIP code (located in RAM) can detect when an
interrupt is pending, suspend the MTD operation, switch the MTD back
to read mode, and then allow the kernel to run.
I'd be nervous about this without Nicolas checking it, or it being
built and the resulting assembly inspected.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 37/62] ARM: sa1100/pxa: fix MTD_XIP build
2014-03-19 20:12 ` Russell King - ARM Linux
@ 2014-03-19 22:00 ` Nicolas Pitre
2014-03-21 16:11 ` Arnd Bergmann
1 sibling, 0 replies; 205+ messages in thread
From: Nicolas Pitre @ 2014-03-19 22:00 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, 19 Mar 2014, Russell King - ARM Linux wrote:
> On Wed, Mar 19, 2014 at 08:29:34PM +0100, Arnd Bergmann wrote:
> > In commit 3169663ac5902 "ARM: sa11x0/pxa: convert OS timer registers
> > to IOMEM", the definition of the OSCR macro was changed to be an
> > __iomem pointer, but the same register is also used by the XIP
> > code. This patch does the corresponding change here as well.
> >
> > Since PXA now uses a local variable for the base address of the
> > ICIP register, the xip_irqpending function has to be moved
> > into irq.c in the process.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Russell King <linux@arm.linux.org.uk>
> > ---
> > arch/arm/mach-pxa/include/mach/mtd-xip.h | 7 ++++---
> > arch/arm/mach-pxa/irq.c | 8 ++++++++
> > arch/arm/mach-sa1100/include/mach/mtd-xip.h | 4 ++--
> > 3 files changed, 14 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/arm/mach-pxa/include/mach/mtd-xip.h b/arch/arm/mach-pxa/include/mach/mtd-xip.h
> > index 990d2bf..c4c90d1 100644
> > --- a/arch/arm/mach-pxa/include/mach/mtd-xip.h
> > +++ b/arch/arm/mach-pxa/include/mach/mtd-xip.h
> > @@ -17,11 +17,12 @@
> >
> > #include <mach/regs-ost.h>
> >
> > -#define xip_irqpending() (ICIP & ICMR)
> > +extern bool xip_irqpending(void);
> >
> > /* we sample OSCR and convert desired delta to usec (1/4 ~= 1000000/3686400) */
> > -#define xip_currtime() (OSCR)
> > -#define xip_elapsed_since(x) (signed)((OSCR - (x)) / 4)
> > +#define xip_irqpending() xip_irqpending()
> > +#define xip_currtime() readl(OSCR)
> > +#define xip_elapsed_since(x) (signed)((readl(OSCR) - (x)) / 4)
>
> I don't think you can do that. I believe xip_irqpending() has to be
> inline so that the XIP code (located in RAM) can detect when an
> interrupt is pending, suspend the MTD operation, switch the MTD back
> to read mode, and then allow the kernel to run.
>
> I'd be nervous about this without Nicolas checking it, or it being
> built and the resulting assembly inspected.
At the very minimum, xip_irqpending() should be marked with the __xipram
attribute.
Nicolas
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 37/62] ARM: sa1100/pxa: fix MTD_XIP build
2014-03-19 20:12 ` Russell King - ARM Linux
2014-03-19 22:00 ` Nicolas Pitre
@ 2014-03-21 16:11 ` Arnd Bergmann
1 sibling, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-21 16:11 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 19 March 2014, Russell King - ARM Linux wrote:
> On Wed, Mar 19, 2014 at 08:29:34PM +0100, Arnd Bergmann wrote:
> > In commit 3169663ac5902 "ARM: sa11x0/pxa: convert OS timer registers
> > to IOMEM", the definition of the OSCR macro was changed to be an
> > __iomem pointer, but the same register is also used by the XIP
> > code. This patch does the corresponding change here as well.
> >
> > Since PXA now uses a local variable for the base address of the
> > ICIP register, the xip_irqpending function has to be moved
> > into irq.c in the process.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Russell King <linux@arm.linux.org.uk>
> > ---
> > arch/arm/mach-pxa/include/mach/mtd-xip.h | 7 ++++---
> > arch/arm/mach-pxa/irq.c | 8 ++++++++
> > arch/arm/mach-sa1100/include/mach/mtd-xip.h | 4 ++--
> > 3 files changed, 14 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/arm/mach-pxa/include/mach/mtd-xip.h b/arch/arm/mach-pxa/include/mach/mtd-xip.h
> > index 990d2bf..c4c90d1 100644
> > --- a/arch/arm/mach-pxa/include/mach/mtd-xip.h
> > +++ b/arch/arm/mach-pxa/include/mach/mtd-xip.h
> > @@ -17,11 +17,12 @@
> >
> > #include <mach/regs-ost.h>
> >
> > -#define xip_irqpending() (ICIP & ICMR)
> > +extern bool xip_irqpending(void);
> >
> > /* we sample OSCR and convert desired delta to usec (1/4 ~= 1000000/3686400) */
> > -#define xip_currtime() (OSCR)
> > -#define xip_elapsed_since(x) (signed)((OSCR - (x)) / 4)
> > +#define xip_irqpending() xip_irqpending()
> > +#define xip_currtime() readl(OSCR)
> > +#define xip_elapsed_since(x) (signed)((readl(OSCR) - (x)) / 4)
>
> I don't think you can do that. I believe xip_irqpending() has to be
> inline so that the XIP code (located in RAM) can detect when an
> interrupt is pending, suspend the MTD operation, switch the MTD back
> to read mode, and then allow the kernel to run.
>
> I'd be nervous about this without Nicolas checking it, or it being
> built and the resulting assembly inspected.
Ok, I'll drop this patch from the series for now, and mark it as
something to be investigated. and apply the change that Nico suggested.
Arnd
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 38/62] ARM: footbridge: don't build floppy code for addin mode
2014-03-19 19:28 ` Arnd Bergmann
` (37 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
-1 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
The ARCH_EBSA285_ADDIN platform does not provide the
ISA_DMA API, which is required by the floppy driver.
Let's ensure that the floppy code can only be built
when ISA_DMA is also enabled, by moving the select
statement into ARCH_EBSA285_HOST.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>
---
| 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--git a/arch/arm/mach-footbridge/Kconfig b/arch/arm/mach-footbridge/Kconfig
index fba55fb..07152d0 100644
--- a/arch/arm/mach-footbridge/Kconfig
+++ b/arch/arm/mach-footbridge/Kconfig
@@ -52,6 +52,7 @@ config ARCH_EBSA285_HOST
select FOOTBRIDGE_HOST
select ISA
select ISA_DMA
+ select ARCH_MAY_HAVE_PC_FDC
select PCI
help
Say Y here if you intend to run this kernel on the EBSA285 card
@@ -94,6 +95,5 @@ config FOOTBRIDGE_ADDIN
# EBSA285 board in either host or addin mode
config ARCH_EBSA285
bool
- select ARCH_MAY_HAVE_PC_FDC
endif
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 39/62] ARM: footbridge: fix build with PCI disabled
2014-03-19 19:28 ` Arnd Bergmann
` (38 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
-1 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
The dc21285.c source file cannot be built when CONFIG_PCI is
disabled, because it calls a number of PCI core interfaces.
This changes the Makefile so we don't include this file in the
build if CONFIG_PCI is disabled. No other code references anything
defined inside of this file in this case.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>
---
| 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--git a/arch/arm/mach-footbridge/Makefile b/arch/arm/mach-footbridge/Makefile
index 0b64dd4..c3faa3b 100644
--- a/arch/arm/mach-footbridge/Makefile
+++ b/arch/arm/mach-footbridge/Makefile
@@ -4,11 +4,12 @@
# Object file lists.
-obj-y := common.o dc21285.o dma.o isa-irq.o
+obj-y := common.o dma.o isa-irq.o
obj-m :=
obj-n :=
obj- :=
+pci-y += dc21285.o
pci-$(CONFIG_ARCH_CATS) += cats-pci.o
pci-$(CONFIG_ARCH_EBSA285_HOST) += ebsa285-pci.o
pci-$(CONFIG_ARCH_NETWINDER) += netwinder-pci.o
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 40/62] ARM: footbridge: make screen_info setup conditional
2014-03-19 19:28 ` Arnd Bergmann
` (39 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
-1 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
The global screen_info structure is used to communicate
data about the console from platform code to the console
driver, but is only defined on ARM if either the VGA or
dummy consoles are in use.
This changes the footbridge code so we don't try to access
this structure in case it is not defined, which prevents
a possible randconfig build error.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>
---
| 2 ++
1 file changed, 2 insertions(+)
--git a/arch/arm/mach-footbridge/cats-hw.c b/arch/arm/mach-footbridge/cats-hw.c
index 9669cc0..da04150 100644
--- a/arch/arm/mach-footbridge/cats-hw.c
+++ b/arch/arm/mach-footbridge/cats-hw.c
@@ -78,9 +78,11 @@ __initcall(cats_hw_init);
static void __init
fixup_cats(struct tag *tags, char **cmdline, struct meminfo *mi)
{
+#if defined(CONFIG_VGA_CONSOLE) || defined(CONFIG_DUMMY_CONSOLE)
screen_info.orig_video_lines = 25;
screen_info.orig_video_points = 16;
screen_info.orig_y = 24;
+#endif
}
MACHINE_START(CATS, "Chalice-CATS")
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 41/62] ARM: realview: fix sparsemem build
2014-03-19 19:28 ` Arnd Bergmann
` (40 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
-1 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
Commit b713aa0b15 "ARM: fix asm/memory.h build error" broke some
configurations on mach-realview with sparsemem enabled, which
is missing a definition of PHYS_OFFSET:
arch/arm/include/asm/memory.h:268:42: error: 'PHYS_OFFSET' undeclared (first use in this function)
#define PHYS_PFN_OFFSET ((unsigned long)(PHYS_OFFSET >> PAGE_SHIFT))
arch/arm/include/asm/dma-mapping.h:104:9: note: in expansion of macro 'PHYS_PFN_OFFSET'
return PHYS_PFN_OFFSET + dma_to_pfn(dev, *dev->dma_mask);
An easy workaround is for realview to define PHYS_OFFSET itself,
in the same way we define it for platforms that don't have a private
__virt_to_phys function.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/mach-realview/include/mach/memory.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-realview/include/mach/memory.h b/arch/arm/mach-realview/include/mach/memory.h
index 2022e09..db09170 100644
--- a/arch/arm/mach-realview/include/mach/memory.h
+++ b/arch/arm/mach-realview/include/mach/memory.h
@@ -56,6 +56,8 @@
#define PAGE_OFFSET1 (PAGE_OFFSET + 0x10000000)
#define PAGE_OFFSET2 (PAGE_OFFSET + 0x30000000)
+#define PHYS_OFFSET PLAT_PHYS_OFFSET
+
#define __phys_to_virt(phys) \
((phys) >= 0x80000000 ? (phys) - 0x80000000 + PAGE_OFFSET2 : \
(phys) >= 0x20000000 ? (phys) - 0x20000000 + PAGE_OFFSET1 : \
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 42/62] ARM: realview: use explicit core tile config options
2014-03-19 19:28 ` Arnd Bergmann
` (41 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-25 14:10 ` Linus Walleij
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
The realview platform can be used with numerous core tiles,
which have to be enabled in the CPU menu at the moment, and
the user has to know at configuration time which CPUs can
be enabled in the same kernel.
Most importantly, it is not a valid configuration to select
both ARMv5 and ARMv6/v7 based CPU cores in the same kernel,
and trying that leads to compile errors.
To make it possible to use realview on randconfig kernels,
and to simplify manual configuration, this lists all
supported combinations of machines and core tiles explicitly
and ensures that we cannot enable the ARM926T CPU if any
ARMv6 or v7 CPU is already enabled.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/mach-realview/Kconfig | 57 ++++++++++++++++++++++++++++++++++++++++++
arch/arm/mm/Kconfig | 8 +++---
2 files changed, 61 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-realview/Kconfig b/arch/arm/mach-realview/Kconfig
index 9db2029..938fd06 100644
--- a/arch/arm/mach-realview/Kconfig
+++ b/arch/arm/mach-realview/Kconfig
@@ -8,6 +8,38 @@ config MACH_REALVIEW_EB
Include support for the ARM(R) RealView(R) Emulation Baseboard
platform.
+config REALVIEW_EB_ARM926
+ bool "Support ARM926EJ-S Tile"
+ depends on MACH_REALVIEW_EB && !(CPU_V6 || CPU_V6K || CPU_V7)
+ select CPU_ARM926T
+ help
+ Enable support for the ARM926 tile fitted to the
+ Realview(R) Emulation Baseboard platform.
+
+config REALVIEW_EB_ARM1136
+ bool "Support ARM1136J(F)-S Tile"
+ depends on MACH_REALVIEW_EB
+ select CPU_V6
+ help
+ Enable support for the ARM1136 tile fitted to the
+ Realview(R) Emulation Baseboard platform.
+
+config REALVIEW_EB_ARM1176
+ bool "Support ARM1176JZ(F)-S Tile"
+ depends on MACH_REALVIEW_EB
+ select CPU_V6K
+ help
+ Enable support for the ARM1176 tile fitted to the
+ Realview(R) Emulation Baseboard platform.
+
+config REALVIEW_EB_V7
+ bool "Support Cortex-A5/A7/A8/A9/A12/A15 Tile"
+ depends on MACH_REALVIEW_EB
+ select CPU_V7
+ help
+ Enable support for Cortex-A class ARMv7-A uniprocessor tiles
+ fitted to the Realview(R) Emulation Baseboard platform.
+
config REALVIEW_EB_A9MP
bool "Support Multicore Cortex-A9 Tile"
depends on MACH_REALVIEW_EB
@@ -101,6 +133,31 @@ config MACH_REALVIEW_PBX
Include support for the ARM(R) RealView(R) Platform Baseboard
Explore.
+config REALVIEW_PBX_ARM1136
+ bool "Support ARM1136J(F)-S Tile"
+ depends on MACH_REALVIEW_PBX
+ select CPU_V6
+ help
+ Enable support for the ARM1136 tile fitted to the
+ Realview(R) Platform Baseboard Explore.
+
+config REALVIEW_PBX_ARM1176
+ bool "Support ARM1176JZ(F)-S Tile"
+ depends on MACH_REALVIEW_PBX
+ select CPU_V6K
+ help
+ Enable support for the ARM1176 tile fitted to the
+ Realview(R) Platform Baseboard Explore.
+
+config REALVIEW_PBX_V7
+ bool "Support Cortex-A5/A7/A8/A9/A12/A15 Tile"
+ depends on MACH_REALVIEW_PBX
+ select CPU_V7
+ help
+ Enable support for Cortex-A class ARMv7-A uniprocessor tiles
+ fitted to the Realview(R) Platform Baseboard Explore.
+
+
config REALVIEW_HIGH_PHYS_OFFSET
bool "High physical base address for the RealView platform"
depends on MMU && !MACH_REALVIEW_PB1176
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 297b63b..8c94496 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -127,7 +127,7 @@ config CPU_ARM925T
# ARM926T
config CPU_ARM926T
- bool "Support ARM926T processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB
+ bool "Support ARM926T processor" if ARCH_INTEGRATOR
select CPU_32v5
select CPU_ABRT_EV5TJ
select CPU_CACHE_VIVT
@@ -358,7 +358,7 @@ config CPU_PJ4B
# ARMv6
config CPU_V6
- bool "Support ARM V6 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX
+ bool "Support ARM V6 processor" if ARCH_INTEGRATOR
select CPU_32v6
select CPU_ABRT_EV6
select CPU_CACHE_V6
@@ -371,7 +371,7 @@ config CPU_V6
# ARMv6k
config CPU_V6K
- bool "Support ARM V6K processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX
+ bool "Support ARM V6K processor" if ARCH_INTEGRATOR
select CPU_32v6
select CPU_32v6K
select CPU_ABRT_EV6
@@ -385,7 +385,7 @@ config CPU_V6K
# ARMv7
config CPU_V7
- bool "Support ARM V7 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX
+ bool "Support ARM V7 processor" if ARCH_INTEGRATOR
select CPU_32v6K
select CPU_32v7
select CPU_ABRT_EV7
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 42/62] ARM: realview: use explicit core tile config options
2014-03-19 19:29 ` [PATCH 42/62] ARM: realview: use explicit core tile config options Arnd Bergmann
@ 2014-03-25 14:10 ` Linus Walleij
2014-03-25 14:37 ` Arnd Bergmann
0 siblings, 1 reply; 205+ messages in thread
From: Linus Walleij @ 2014-03-25 14:10 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Mar 19, 2014 at 8:29 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> The realview platform can be used with numerous core tiles,
> which have to be enabled in the CPU menu at the moment, and
> the user has to know at configuration time which CPUs can
> be enabled in the same kernel.
>
> Most importantly, it is not a valid configuration to select
> both ARMv5 and ARMv6/v7 based CPU cores in the same kernel,
> and trying that leads to compile errors.
>
> To make it possible to use realview on randconfig kernels,
> and to simplify manual configuration, this lists all
> supported combinations of machines and core tiles explicitly
> and ensures that we cannot enable the ARM926T CPU if any
> ARMv6 or v7 CPU is already enabled.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Linus Walleij <linus.walleij@linaro.org>
Looks good to me, I'd ask Will and/or Marc to have a look at this
and confirm.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 42/62] ARM: realview: use explicit core tile config options
2014-03-25 14:10 ` Linus Walleij
@ 2014-03-25 14:37 ` Arnd Bergmann
0 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-25 14:37 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 25 March 2014 15:10:31 Linus Walleij wrote:
> On Wed, Mar 19, 2014 at 8:29 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> > The realview platform can be used with numerous core tiles,
> > which have to be enabled in the CPU menu at the moment, and
> > the user has to know at configuration time which CPUs can
> > be enabled in the same kernel.
> >
> > Most importantly, it is not a valid configuration to select
> > both ARMv5 and ARMv6/v7 based CPU cores in the same kernel,
> > and trying that leads to compile errors.
> >
> > To make it possible to use realview on randconfig kernels,
> > and to simplify manual configuration, this lists all
> > supported combinations of machines and core tiles explicitly
> > and ensures that we cannot enable the ARM926T CPU if any
> > ARMv6 or v7 CPU is already enabled.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Russell King <linux@arm.linux.org.uk>
> > Cc: Linus Walleij <linus.walleij@linaro.org>
>
> Looks good to me, I'd ask Will and/or Marc to have a look at this
> and confirm.
I actually dropped it already, along with the integrator patch
of the same purpose. It will become easier when they are both
multiplatform enabled.
Arnd
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 43/62] ARM: integrator: only select pl01x if TTY is enabled
2014-03-19 19:28 ` Arnd Bergmann
` (42 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-25 14:09 ` Linus Walleij
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
Building the integrator platform without TTY support currently
results in a build failure because we always turn on the
pl010 or pl011 drivers. Changing this to a conditional 'select'
statement enables us to build more random configurations, although
it should have little impact for practical configurations.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/mach-integrator/Kconfig | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-integrator/Kconfig b/arch/arm/mach-integrator/Kconfig
index 6e8b0e1..ba43321 100644
--- a/arch/arm/mach-integrator/Kconfig
+++ b/arch/arm/mach-integrator/Kconfig
@@ -6,8 +6,8 @@ config ARCH_INTEGRATOR_AP
bool "Support Integrator/AP and Integrator/PP2 platforms"
select CLKSRC_MMIO
select MIGHT_HAVE_PCI
- select SERIAL_AMBA_PL010
- select SERIAL_AMBA_PL010_CONSOLE
+ select SERIAL_AMBA_PL010 if TTY
+ select SERIAL_AMBA_PL010_CONSOLE if TTY
select SOC_BUS
help
Include support for the ARM(R) Integrator/AP and
@@ -18,8 +18,8 @@ config ARCH_INTEGRATOR_CP
select ARCH_CINTEGRATOR
select ARM_TIMER_SP804
select PLAT_VERSATILE_CLCD
- select SERIAL_AMBA_PL011
- select SERIAL_AMBA_PL011_CONSOLE
+ select SERIAL_AMBA_PL011 if TTY
+ select SERIAL_AMBA_PL011_CONSOLE if TTY
select SOC_BUS
help
Include support for the ARM(R) Integrator CP platform.
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 43/62] ARM: integrator: only select pl01x if TTY is enabled
2014-03-19 19:29 ` [PATCH 43/62] ARM: integrator: only select pl01x if TTY is enabled Arnd Bergmann
@ 2014-03-25 14:09 ` Linus Walleij
0 siblings, 0 replies; 205+ messages in thread
From: Linus Walleij @ 2014-03-25 14:09 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Mar 19, 2014 at 8:29 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> Building the integrator platform without TTY support currently
> results in a build failure because we always turn on the
> pl010 or pl011 drivers. Changing this to a conditional 'select'
> statement enables us to build more random configurations, although
> it should have little impact for practical configurations.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 44/62] ARM: integrator: refine CPU selection
2014-03-19 19:28 ` Arnd Bergmann
` (43 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-19 20:49 ` Russell King - ARM Linux
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
This adds a new Kconfig option for the Integrator platform to
choose between ARMv4/ARMv5 based CPUs and those based on ARMv6/ARMv7,
which is required because we cannot have both classes enabled in the
same kernel at compile time.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/mach-integrator/Kconfig | 11 +++++++++++
arch/arm/mm/Kconfig | 28 ++++++++++++++--------------
2 files changed, 25 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-integrator/Kconfig b/arch/arm/mach-integrator/Kconfig
index ba43321..8c797e77 100644
--- a/arch/arm/mach-integrator/Kconfig
+++ b/arch/arm/mach-integrator/Kconfig
@@ -2,6 +2,17 @@ if ARCH_INTEGRATOR
menu "Integrator Options"
+choice
+ prompt "CPU architecture level"
+
+config ARCH_INTEGRATOR_V4_V5
+ bool "ARMv4 or ARMv5 CPUs"
+
+config ARCH_INTEGRATOR_V6_V7
+ bool "ARMv6 or ARMv7 CPUs"
+
+endchoice
+
config ARCH_INTEGRATOR_AP
bool "Support Integrator/AP and Integrator/PP2 platforms"
select CLKSRC_MMIO
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 8c94496..af76df4 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -21,7 +21,7 @@ config CPU_ARM7TDMI
# ARM720T
config CPU_ARM720T
- bool "Support ARM720T processor" if ARCH_INTEGRATOR
+ bool "Support ARM720T processor" if ARCH_INTEGRATOR_V4_V5
select CPU_32v4T
select CPU_ABRT_LV4T
select CPU_CACHE_V4
@@ -39,7 +39,7 @@ config CPU_ARM720T
# ARM740T
config CPU_ARM740T
- bool "Support ARM740T processor" if ARCH_INTEGRATOR
+ bool "Support ARM740T processor" if ARCH_INTEGRATOR_V4_V5
depends on !MMU
select CPU_32v4T
select CPU_ABRT_LV4T
@@ -71,7 +71,7 @@ config CPU_ARM9TDMI
# ARM920T
config CPU_ARM920T
- bool "Support ARM920T processor" if ARCH_INTEGRATOR
+ bool "Support ARM920T processor" if ARCH_INTEGRATOR_V4_V5
select CPU_32v4T
select CPU_ABRT_EV4T
select CPU_CACHE_V4WT
@@ -89,7 +89,7 @@ config CPU_ARM920T
# ARM922T
config CPU_ARM922T
- bool "Support ARM922T processor" if ARCH_INTEGRATOR
+ bool "Support ARM922T processor" if ARCH_INTEGRATOR_V4_V5
select CPU_32v4T
select CPU_ABRT_EV4T
select CPU_CACHE_V4WT
@@ -127,7 +127,7 @@ config CPU_ARM925T
# ARM926T
config CPU_ARM926T
- bool "Support ARM926T processor" if ARCH_INTEGRATOR
+ bool "Support ARM926T processor" if ARCH_INTEGRATOR_V4_V5
select CPU_32v5
select CPU_ABRT_EV5TJ
select CPU_CACHE_VIVT
@@ -163,7 +163,7 @@ config CPU_FA526
# ARM940T
config CPU_ARM940T
- bool "Support ARM940T processor" if ARCH_INTEGRATOR
+ bool "Support ARM940T processor" if ARCH_INTEGRATOR_V4_V5
depends on !MMU
select CPU_32v4T
select CPU_ABRT_NOMMU
@@ -181,7 +181,7 @@ config CPU_ARM940T
# ARM946E-S
config CPU_ARM946E
- bool "Support ARM946E-S processor" if ARCH_INTEGRATOR
+ bool "Support ARM946E-S processor" if ARCH_INTEGRATOR_V4_V5
depends on !MMU
select CPU_32v5
select CPU_ABRT_NOMMU
@@ -198,7 +198,7 @@ config CPU_ARM946E
# ARM1020 - needs validating
config CPU_ARM1020
- bool "Support ARM1020T (rev 0) processor" if ARCH_INTEGRATOR
+ bool "Support ARM1020T (rev 0) processor" if ARCH_INTEGRATOR_V4_V5
select CPU_32v5
select CPU_ABRT_EV4T
select CPU_CACHE_V4WT
@@ -216,7 +216,7 @@ config CPU_ARM1020
# ARM1020E - needs validating
config CPU_ARM1020E
- bool "Support ARM1020E processor" if ARCH_INTEGRATOR
+ bool "Support ARM1020E processor" if ARCH_INTEGRATOR_V4_V5
depends on n
select CPU_32v5
select CPU_ABRT_EV4T
@@ -229,7 +229,7 @@ config CPU_ARM1020E
# ARM1022E
config CPU_ARM1022
- bool "Support ARM1022E processor" if ARCH_INTEGRATOR
+ bool "Support ARM1022E processor" if ARCH_INTEGRATOR_V4_V5
select CPU_32v5
select CPU_ABRT_EV4T
select CPU_CACHE_VIVT
@@ -247,7 +247,7 @@ config CPU_ARM1022
# ARM1026EJ-S
config CPU_ARM1026
- bool "Support ARM1026EJ-S processor" if ARCH_INTEGRATOR
+ bool "Support ARM1026EJ-S processor" if ARCH_INTEGRATOR_V4_V5
select CPU_32v5
select CPU_ABRT_EV5T # But need Jazelle, but EV5TJ ignores bit 10
select CPU_CACHE_VIVT
@@ -358,7 +358,7 @@ config CPU_PJ4B
# ARMv6
config CPU_V6
- bool "Support ARM V6 processor" if ARCH_INTEGRATOR
+ bool "Support ARM V6 processor" if ARCH_INTEGRATOR_V6_V7
select CPU_32v6
select CPU_ABRT_EV6
select CPU_CACHE_V6
@@ -371,7 +371,7 @@ config CPU_V6
# ARMv6k
config CPU_V6K
- bool "Support ARM V6K processor" if ARCH_INTEGRATOR
+ bool "Support ARM V6K processor" if ARCH_INTEGRATOR_V6_V7
select CPU_32v6
select CPU_32v6K
select CPU_ABRT_EV6
@@ -385,7 +385,7 @@ config CPU_V6K
# ARMv7
config CPU_V7
- bool "Support ARM V7 processor" if ARCH_INTEGRATOR
+ bool "Support ARM V7 processor" if ARCH_INTEGRATOR_V6_V7
select CPU_32v6K
select CPU_32v7
select CPU_ABRT_EV7
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 44/62] ARM: integrator: refine CPU selection
2014-03-19 19:29 ` [PATCH 44/62] ARM: integrator: refine CPU selection Arnd Bergmann
@ 2014-03-19 20:49 ` Russell King - ARM Linux
2014-03-19 21:05 ` Arnd Bergmann
0 siblings, 1 reply; 205+ messages in thread
From: Russell King - ARM Linux @ 2014-03-19 20:49 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Mar 19, 2014 at 08:29:41PM +0100, Arnd Bergmann wrote:
> This adds a new Kconfig option for the Integrator platform to
> choose between ARMv4/ARMv5 based CPUs and those based on ARMv6/ARMv7,
> which is required because we cannot have both classes enabled in the
> same kernel at compile time.
Wouldn't it just be easier to make the older CPUs depend on
!CPU_V6 && !CPU_V7 rather than trying to hack this for each platform?
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 44/62] ARM: integrator: refine CPU selection
2014-03-19 20:49 ` Russell King - ARM Linux
@ 2014-03-19 21:05 ` Arnd Bergmann
2014-03-20 10:48 ` Arnd Bergmann
0 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 21:05 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 19 March 2014 20:49:47 Russell King - ARM Linux wrote:
> On Wed, Mar 19, 2014 at 08:29:41PM +0100, Arnd Bergmann wrote:
> > This adds a new Kconfig option for the Integrator platform to
> > choose between ARMv4/ARMv5 based CPUs and those based on ARMv6/ARMv7,
> > which is required because we cannot have both classes enabled in the
> > same kernel at compile time.
>
> Wouldn't it just be easier to make the older CPUs depend on
> !CPU_V6 && !CPU_V7 rather than trying to hack this for each platform?
It's only two platforms: integrator and realview. Actually I took two
different approaches on these, and wanted to make up my mind first
which one is better. Any suggestion?
I have a mild preference to always using 'select' on the CPU_* symbol
from the platform, mostly for consistency. The downside is that it
gets a little messy for Integrator, but that's just one platform in
the end.
At some point, I think I got into circular dependencies when one CPU
depended on another one being disabled, but I don't remember exactly
what case that was.
Arnd
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 44/62] ARM: integrator: refine CPU selection
2014-03-19 21:05 ` Arnd Bergmann
@ 2014-03-20 10:48 ` Arnd Bergmann
2014-03-25 20:34 ` Linus Walleij
0 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-20 10:48 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 19 March 2014, Arnd Bergmann wrote:
> On Wednesday 19 March 2014 20:49:47 Russell King - ARM Linux wrote:
> > On Wed, Mar 19, 2014 at 08:29:41PM +0100, Arnd Bergmann wrote:
> > > This adds a new Kconfig option for the Integrator platform to
> > > choose between ARMv4/ARMv5 based CPUs and those based on ARMv6/ARMv7,
> > > which is required because we cannot have both classes enabled in the
> > > same kernel at compile time.
> >
> > Wouldn't it just be easier to make the older CPUs depend on
> > !CPU_V6 && !CPU_V7 rather than trying to hack this for each platform?
>
> It's only two platforms: integrator and realview. Actually I took two
> different approaches on these, and wanted to make up my mind first
> which one is better. Any suggestion?
>
> I have a mild preference to always using 'select' on the CPU_* symbol
> from the platform, mostly for consistency. The downside is that it
> gets a little messy for Integrator, but that's just one platform in
> the end.
>
> At some point, I think I got into circular dependencies when one CPU
> depended on another one being disabled, but I don't remember exactly
> what case that was.
>
Nevermind, I'll drop this patch for now, I just had an idea to do it
better: Since Linus and I are trying to get Integrator and Realview
moved over into ARCH_MULTIPLATFORM anyway, I'll defer the CPU selection
question until that's done.
Within ARCH_MULTIPLATFORM, we already want to deal with booting machines
that are described entirely in DT and have no platform specific code,
but we also want to be able to select the CPU types built into the
kernel for them.
For the v6/v6k/v7 selection, we can do this through the top-level
multiplatform options we already have, as we don't expose the
differences between the individual core implementations for the most
part. We can potentially leave PJ4 and PJ4B as user-selectable.
For the v4/v4t/v5 selection, I would allow any CPU to be manually
enabled with a dependency on the ARCH_MULTI_V* option. Platforms
that know what they have should obviously keep selecting the one
they want. I would leave strongarm and xscale out of the selection,
because I don't expect any platform based on those cores to ever
become enabled for ARCH_MULTIPLATFORM, but all the others should
be selectable.
For the moment, I'll keep using my patches locally in order to
keep randconfig building, and I'll follow up with a new patch
after integrator and realview are part of multiplatform. That
may take a while, but I'm sure we'll get there eventually.
Arnd
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 44/62] ARM: integrator: refine CPU selection
2014-03-20 10:48 ` Arnd Bergmann
@ 2014-03-25 20:34 ` Linus Walleij
2014-03-25 23:42 ` Arnd Bergmann
0 siblings, 1 reply; 205+ messages in thread
From: Linus Walleij @ 2014-03-25 20:34 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Mar 20, 2014 at 11:48 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> Nevermind, I'll drop this patch for now, I just had an idea to do it
> better: Since Linus and I are trying to get Integrator and Realview
> moved over into ARCH_MULTIPLATFORM anyway, I'll defer the CPU selection
> question until that's done.
Integrator is blocked by one single thing: <mach/memory.h>
bus_to_virt/virt_to_bus.
If we can get some consensus on Santosh's patches
(or however we want to solve that) I'll do multiplatform for
Integrator any day.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 44/62] ARM: integrator: refine CPU selection
2014-03-25 20:34 ` Linus Walleij
@ 2014-03-25 23:42 ` Arnd Bergmann
2014-03-26 10:27 ` Linus Walleij
0 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-25 23:42 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 25 March 2014 21:34:21 Linus Walleij wrote:
> On Thu, Mar 20, 2014 at 11:48 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> > Nevermind, I'll drop this patch for now, I just had an idea to do it
> > better: Since Linus and I are trying to get Integrator and Realview
> > moved over into ARCH_MULTIPLATFORM anyway, I'll defer the CPU selection
> > question until that's done.
>
> Integrator is blocked by one single thing: <mach/memory.h>
> bus_to_virt/virt_to_bus.
>
> If we can get some consensus on Santosh's patches
> (or however we want to solve that) I'll do multiplatform for
> Integrator any day.
Yes, I know. My point is that once the two are multiplatform, we wouldn't
do the CPU selection patches like this anymore. Instead, I would just do
config CPU_ARM920T
bool "Support ARM920T processor" if ARCH_MULTI_V4T
...
config CPU_ARM926T
bool "Support ARM920T processor" if ARCH_MULTI_V5
...
...
In a multiplatform kernel, there is nothing wrong with just letting
users turn on arbitrary combinations of CPUs as long as they are
compatible at run-time (i.e. not v5+v7 combined). This will also let
you run qemu images using the MACH_VIRT target and any CPU emulation.
Of course, most platforms will still select the CPUs they actually
use, but you can always add more.
Arnd
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 44/62] ARM: integrator: refine CPU selection
2014-03-25 23:42 ` Arnd Bergmann
@ 2014-03-26 10:27 ` Linus Walleij
0 siblings, 0 replies; 205+ messages in thread
From: Linus Walleij @ 2014-03-26 10:27 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Mar 26, 2014 at 12:42 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> My point is that once the two are multiplatform, we wouldn't
> do the CPU selection patches like this anymore. Instead, I would just do
>
> config CPU_ARM920T
> bool "Support ARM920T processor" if ARCH_MULTI_V4T
> ...
>
> config CPU_ARM926T
> bool "Support ARM920T processor" if ARCH_MULTI_V5
> ...
Ah I see, that's elegant. Yes let's go for this.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 45/62] ARM: s3c24xx: MINI2440 needs I2C for EEPROM_AT24
2014-03-19 19:28 ` Arnd Bergmann
` (44 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-20 3:48 ` Kukjin Kim
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
If I2C is disabled, we cannot build the AT24 driver, so we
should not select it.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
arch/arm/mach-s3c24xx/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index bb1fa603..a6060d0 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -536,7 +536,7 @@ config MACH_AT2440EVB
config MACH_MINI2440
bool "MINI2440 development board"
- select EEPROM_AT24
+ select EEPROM_AT24 if I2C
select LEDS_CLASS
select LEDS_TRIGGERS
select LEDS_TRIGGER_BACKLIGHT
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 45/62] ARM: s3c24xx: MINI2440 needs I2C for EEPROM_AT24
2014-03-19 19:29 ` [PATCH 45/62] ARM: s3c24xx: MINI2440 needs I2C for EEPROM_AT24 Arnd Bergmann
@ 2014-03-20 3:48 ` Kukjin Kim
0 siblings, 0 replies; 205+ messages in thread
From: Kukjin Kim @ 2014-03-20 3:48 UTC (permalink / raw)
To: linux-arm-kernel
Arnd Bergmann wrote:
>
> If I2C is disabled, we cannot build the AT24 driver, so we
> should not select it.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Kukjin Kim <kgene.kim@samsung.com>
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Thanks,
Kukjin
> Cc: Ben Dooks <ben-linux@fluff.org>
> ---
> arch/arm/mach-s3c24xx/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
> index bb1fa603..a6060d0 100644
> --- a/arch/arm/mach-s3c24xx/Kconfig
> +++ b/arch/arm/mach-s3c24xx/Kconfig
> @@ -536,7 +536,7 @@ config MACH_AT2440EVB
>
> config MACH_MINI2440
> bool "MINI2440 development board"
> - select EEPROM_AT24
> + select EEPROM_AT24 if I2C
> select LEDS_CLASS
> select LEDS_TRIGGERS
> select LEDS_TRIGGER_BACKLIGHT
> --
> 1.8.3.2
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 46/62] ARM: s3c24xx: fix gta02 build error
2014-03-19 19:28 ` Arnd Bergmann
` (45 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-20 3:48 ` Kukjin Kim
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
The gta02 has always been broken in the case when CONFIG_PCF50633_ADC
is not used, since gta02_charger_worker then passes a nonexisting
variable into the pcf50633_mbc_usb_curlim_set() function.
This addresses the obvious typo by using the variable that is
used everywhere else in this file.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
arch/arm/mach-s3c24xx/mach-gta02.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-s3c24xx/mach-gta02.c b/arch/arm/mach-s3c24xx/mach-gta02.c
index 8e05813..dc4db84 100644
--- a/arch/arm/mach-s3c24xx/mach-gta02.c
+++ b/arch/arm/mach-s3c24xx/mach-gta02.c
@@ -196,7 +196,7 @@ static void gta02_charger_worker(struct work_struct *work)
* If the PCF50633 ADC is disabled we fallback to a
* 100mA limit for safety.
*/
- pcf50633_mbc_usb_curlim_set(pcf, 100);
+ pcf50633_mbc_usb_curlim_set(gta02_pcf, 100);
#endif
}
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 46/62] ARM: s3c24xx: fix gta02 build error
2014-03-19 19:29 ` [PATCH 46/62] ARM: s3c24xx: fix gta02 build error Arnd Bergmann
@ 2014-03-20 3:48 ` Kukjin Kim
0 siblings, 0 replies; 205+ messages in thread
From: Kukjin Kim @ 2014-03-20 3:48 UTC (permalink / raw)
To: linux-arm-kernel
Arnd Bergmann wrote:
>
> The gta02 has always been broken in the case when CONFIG_PCF50633_ADC
> is not used, since gta02_charger_worker then passes a nonexisting
> variable into the pcf50633_mbc_usb_curlim_set() function.
>
> This addresses the obvious typo by using the variable that is
> used everywhere else in this file.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Kukjin Kim <kgene.kim@samsung.com>
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Thanks,
Kukjin
> Cc: Ben Dooks <ben-linux@fluff.org>
> ---
> arch/arm/mach-s3c24xx/mach-gta02.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-s3c24xx/mach-gta02.c b/arch/arm/mach-
> s3c24xx/mach-gta02.c
> index 8e05813..dc4db84 100644
> --- a/arch/arm/mach-s3c24xx/mach-gta02.c
> +++ b/arch/arm/mach-s3c24xx/mach-gta02.c
> @@ -196,7 +196,7 @@ static void gta02_charger_worker(struct work_struct
> *work)
> * If the PCF50633 ADC is disabled we fallback to a
> * 100mA limit for safety.
> */
> - pcf50633_mbc_usb_curlim_set(pcf, 100);
> + pcf50633_mbc_usb_curlim_set(gta02_pcf, 100);
> #endif
> }
>
> --
> 1.8.3.2
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 47/62] ARM: s3c64xx: MACH_SMDK6400 needs HSMMC1
2014-03-19 19:28 ` Arnd Bergmann
` (46 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-20 3:55 ` Kukjin Kim
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
This board uses both MMC controllers, so we need to enable
the Kconfig option to define the platform data.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
arch/arm/mach-s3c64xx/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
index 64f04e6..92885d7 100644
--- a/arch/arm/mach-s3c64xx/Kconfig
+++ b/arch/arm/mach-s3c64xx/Kconfig
@@ -87,6 +87,7 @@ config MACH_SMDK6400
select CPU_S3C6400
select S3C64XX_SETUP_SDHCI
select S3C_DEV_HSMMC
+ select S3C_DEV_HSMMC1
select S3C_DEV_NAND
help
Machine support for the Samsung SMDK6400
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 47/62] ARM: s3c64xx: MACH_SMDK6400 needs HSMMC1
2014-03-19 19:29 ` [PATCH 47/62] ARM: s3c64xx: MACH_SMDK6400 needs HSMMC1 Arnd Bergmann
@ 2014-03-20 3:55 ` Kukjin Kim
2014-03-21 16:13 ` Arnd Bergmann
0 siblings, 1 reply; 205+ messages in thread
From: Kukjin Kim @ 2014-03-20 3:55 UTC (permalink / raw)
To: linux-arm-kernel
Arnd Bergmann wrote:
>
> This board uses both MMC controllers, so we need to enable
> the Kconfig option to define the platform data.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Kukjin Kim <kgene.kim@samsung.com>
> Cc: Ben Dooks <ben-linux@fluff.org>
> ---
> arch/arm/mach-s3c64xx/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
> index 64f04e6..92885d7 100644
> --- a/arch/arm/mach-s3c64xx/Kconfig
> +++ b/arch/arm/mach-s3c64xx/Kconfig
> @@ -87,6 +87,7 @@ config MACH_SMDK6400
> select CPU_S3C6400
> select S3C64XX_SETUP_SDHCI
> select S3C_DEV_HSMMC
> + select S3C_DEV_HSMMC1
> select S3C_DEV_NAND
Well, only HSMMC ch1 is used on smdk6400 and S3C_DEV_NAND is not needed.
So should be following:
diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
index 64f04e6..3136d86 100644
--- a/arch/arm/mach-s3c64xx/Kconfig
+++ b/arch/arm/mach-s3c64xx/Kconfig
@@ -86,8 +86,7 @@ config MACH_SMDK6400
bool "SMDK6400"
select CPU_S3C6400
select S3C64XX_SETUP_SDHCI
- select S3C_DEV_HSMMC
- select S3C_DEV_NAND
+ select S3C_DEV_HSMMC1
help
Machine support for the Samsung SMDK6400
Thanks,
Kukjin
> help
> Machine support for the Samsung SMDK6400
> --
> 1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 47/62] ARM: s3c64xx: MACH_SMDK6400 needs HSMMC1
2014-03-20 3:55 ` Kukjin Kim
@ 2014-03-21 16:13 ` Arnd Bergmann
2014-03-21 23:40 ` Kukjin Kim
0 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-21 16:13 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 20 March 2014, Kukjin Kim wrote:
>
> Well, only HSMMC ch1 is used on smdk6400 and S3C_DEV_NAND is not needed.
Ok, changed it now as you suggested:
>From 9ec2109585b54ed8ff507e4b29c8fee7af14c70d Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Wed, 26 Feb 2014 21:31:18 +0100
Subject: [PATCH] ARM: s3c64xx: MACH_SMDK6400 needs HSMMC1
This board uses both MMC controllers, so we need to enable
the Kconfig option to define the platform data.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
index 64f04e6..3136d86 100644
--- a/arch/arm/mach-s3c64xx/Kconfig
+++ b/arch/arm/mach-s3c64xx/Kconfig
@@ -86,8 +86,7 @@ config MACH_SMDK6400
bool "SMDK6400"
select CPU_S3C6400
select S3C64XX_SETUP_SDHCI
- select S3C_DEV_HSMMC
- select S3C_DEV_NAND
+ select S3C_DEV_HSMMC1
help
Machine support for the Samsung SMDK6400
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 47/62] ARM: s3c64xx: MACH_SMDK6400 needs HSMMC1
2014-03-21 16:13 ` Arnd Bergmann
@ 2014-03-21 23:40 ` Kukjin Kim
0 siblings, 0 replies; 205+ messages in thread
From: Kukjin Kim @ 2014-03-21 23:40 UTC (permalink / raw)
To: linux-arm-kernel
Arnd Bergmann wrote:
>
> On Thursday 20 March 2014, Kukjin Kim wrote:
> >
> > Well, only HSMMC ch1 is used on smdk6400 and S3C_DEV_NAND is not needed.
>
> Ok, changed it now as you suggested:
>
> From 9ec2109585b54ed8ff507e4b29c8fee7af14c70d Mon Sep 17 00:00:00 2001
> From: Arnd Bergmann <arnd@arndb.de>
> Date: Wed, 26 Feb 2014 21:31:18 +0100
> Subject: [PATCH] ARM: s3c64xx: MACH_SMDK6400 needs HSMMC1
>
> This board uses both MMC controllers, so we need to enable
> the Kconfig option to define the platform data.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Kukjin Kim <kgene.kim@samsung.com>
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Thanks,
Kukjin
> Cc: Ben Dooks <ben-linux@fluff.org>
>
> diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
> index 64f04e6..3136d86 100644
> --- a/arch/arm/mach-s3c64xx/Kconfig
> +++ b/arch/arm/mach-s3c64xx/Kconfig
> @@ -86,8 +86,7 @@ config MACH_SMDK6400
> bool "SMDK6400"
> select CPU_S3C6400
> select S3C64XX_SETUP_SDHCI
> - select S3C_DEV_HSMMC
> - select S3C_DEV_NAND
> + select S3C_DEV_HSMMC1
> help
> Machine support for the Samsung SMDK6400
>
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 48/62] ARM: s3c64xx: select power domains only when used
2014-03-19 19:28 ` Arnd Bergmann
` (47 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-20 3:56 ` Kukjin Kim
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
The power domain code is only available when CONFIG_PM
is enabled, so we must not select that unconditionally for
s3c64xx. Changing it to 'select PM_GENERIC_DOMAINS if PM'
mirrors what we do on other platforms, and fixes a possible
randconfig build bug.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
arch/arm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 4721007..6ffcadd 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -764,7 +764,7 @@ config ARCH_S3C64XX
select HAVE_TCM
select NO_IOPORT
select PLAT_SAMSUNG
- select PM_GENERIC_DOMAINS
+ select PM_GENERIC_DOMAINS if PM
select S3C_DEV_NAND
select S3C_GPIO_TRACK
select SAMSUNG_ATAGS
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 48/62] ARM: s3c64xx: select power domains only when used
2014-03-19 19:29 ` [PATCH 48/62] ARM: s3c64xx: select power domains only when used Arnd Bergmann
@ 2014-03-20 3:56 ` Kukjin Kim
2014-03-20 18:14 ` Kukjin Kim
0 siblings, 1 reply; 205+ messages in thread
From: Kukjin Kim @ 2014-03-20 3:56 UTC (permalink / raw)
To: linux-arm-kernel
Arnd Bergmann wrote:
>
> The power domain code is only available when CONFIG_PM
> is enabled, so we must not select that unconditionally for
> s3c64xx. Changing it to 'select PM_GENERIC_DOMAINS if PM'
> mirrors what we do on other platforms, and fixes a possible
> randconfig build bug.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Kukjin Kim <kgene.kim@samsung.com>
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Thanks,
Kukjin
> Cc: Ben Dooks <ben-linux@fluff.org>
> ---
> arch/arm/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 4721007..6ffcadd 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -764,7 +764,7 @@ config ARCH_S3C64XX
> select HAVE_TCM
> select NO_IOPORT
> select PLAT_SAMSUNG
> - select PM_GENERIC_DOMAINS
> + select PM_GENERIC_DOMAINS if PM
> select S3C_DEV_NAND
> select S3C_GPIO_TRACK
> select SAMSUNG_ATAGS
> --
> 1.8.3.2
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 48/62] ARM: s3c64xx: select power domains only when used
2014-03-20 3:56 ` Kukjin Kim
@ 2014-03-20 18:14 ` Kukjin Kim
2014-03-20 22:39 ` Kukjin Kim
0 siblings, 1 reply; 205+ messages in thread
From: Kukjin Kim @ 2014-03-20 18:14 UTC (permalink / raw)
To: linux-arm-kernel
On 03/20/14 12:56, Kukjin Kim wrote:
> Arnd Bergmann wrote:
>>
>> The power domain code is only available when CONFIG_PM
>> is enabled, so we must not select that unconditionally for
>> s3c64xx. Changing it to 'select PM_GENERIC_DOMAINS if PM'
>> mirrors what we do on other platforms, and fixes a possible
>> randconfig build bug.
>>
>> Signed-off-by: Arnd Bergmann<arnd@arndb.de>
>> Cc: Tomasz Figa<tomasz.figa@gmail.com>
>> Cc: Kukjin Kim<kgene.kim@samsung.com>
>
> Acked-by: Kukjin Kim<kgene.kim@samsung.com>
>
Arnd,
Please drop this patch in your tree because there is a fix before this
and it fixes SAMSUNG_WAKEMASK dependency together for S3C64XX.
[PATCH v2 5/6] ARM: s3c64xx: Fix incorrect selection of PM-related
symbols <http://www.spinics.net/lists/arm-kernel/msg316391.html>
Note, I'll take above into 2nd fixes for v3.15 in samsung tree.
If any problems, please kindly let me know.
Thanks,
Kukjin
> Thanks,
> Kukjin
>
>> Cc: Ben Dooks<ben-linux@fluff.org>
>> ---
>> arch/arm/Kconfig | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index 4721007..6ffcadd 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -764,7 +764,7 @@ config ARCH_S3C64XX
>> select HAVE_TCM
>> select NO_IOPORT
>> select PLAT_SAMSUNG
>> - select PM_GENERIC_DOMAINS
>> + select PM_GENERIC_DOMAINS if PM
>> select S3C_DEV_NAND
>> select S3C_GPIO_TRACK
>> select SAMSUNG_ATAGS
>> --
>> 1.8.3.2
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 48/62] ARM: s3c64xx: select power domains only when used
2014-03-20 18:14 ` Kukjin Kim
@ 2014-03-20 22:39 ` Kukjin Kim
0 siblings, 0 replies; 205+ messages in thread
From: Kukjin Kim @ 2014-03-20 22:39 UTC (permalink / raw)
To: linux-arm-kernel
On 03/21/14 03:14, Kukjin Kim wrote:
> On 03/20/14 12:56, Kukjin Kim wrote:
>> Arnd Bergmann wrote:
>>>
>>> The power domain code is only available when CONFIG_PM
>>> is enabled, so we must not select that unconditionally for
>>> s3c64xx. Changing it to 'select PM_GENERIC_DOMAINS if PM'
>>> mirrors what we do on other platforms, and fixes a possible
>>> randconfig build bug.
>>>
>>> Signed-off-by: Arnd Bergmann<arnd@arndb.de>
>>> Cc: Tomasz Figa<tomasz.figa@gmail.com>
>>> Cc: Kukjin Kim<kgene.kim@samsung.com>
>>
>> Acked-by: Kukjin Kim<kgene.kim@samsung.com>
>>
>
> Arnd,
>
> Please drop this patch in your tree because there is a fix before this
> and it fixes SAMSUNG_WAKEMASK dependency together for S3C64XX.
>
> [PATCH v2 5/6] ARM: s3c64xx: Fix incorrect selection of PM-related
> symbols <http://www.spinics.net/lists/arm-kernel/msg316391.html>
>
> Note, I'll take above into 2nd fixes for v3.15 in samsung tree.
>
> If any problems, please kindly let me know.
>
Oops, Arnd sorry.
Please go ahead with my ack on this because the fix, "[PATCH v2 5/6]
ARM: s3c64xx: Fix incorrect selection of PM-related symbols" makes a
build error...I'll look at the problem.
Thanks,
Kukjin
>>
>>> Cc: Ben Dooks<ben-linux@fluff.org>
>>> ---
>>> arch/arm/Kconfig | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>> index 4721007..6ffcadd 100644
>>> --- a/arch/arm/Kconfig
>>> +++ b/arch/arm/Kconfig
>>> @@ -764,7 +764,7 @@ config ARCH_S3C64XX
>>> select HAVE_TCM
>>> select NO_IOPORT
>>> select PLAT_SAMSUNG
>>> - select PM_GENERIC_DOMAINS
>>> + select PM_GENERIC_DOMAINS if PM
>>> select S3C_DEV_NAND
>>> select S3C_GPIO_TRACK
>>> select SAMSUNG_ATAGS
>>> --
>>> 1.8.3.2
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 49/62] ARM: s5p64x0: fix building with only one soc type
2014-03-19 19:28 ` Arnd Bergmann
` (48 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-20 3:59 ` Kukjin Kim
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
The s5p64x0 platform supports two distinct SoCs, s5p6440 and s5p6450,
and in the normal configuration, both are enabled. However if we build
a kernel that only enables one of the two, the #ifdef logic in common.c
breaks down, as some of the functions declared in the header are defined
to NULL using the preprocessor but then defined anyway.
This patch cleans up the mess and ensures that each function has either
exactly one C declaration and one matching C definition, or we have
a NULL defined function pointer but no C definition.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
arch/arm/mach-s5p64x0/common.c | 18 ++++++++++++++++--
arch/arm/mach-s5p64x0/common.h | 5 +----
2 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-s5p64x0/common.c b/arch/arm/mach-s5p64x0/common.c
index eb2ad14..9a43be0 100644
--- a/arch/arm/mach-s5p64x0/common.c
+++ b/arch/arm/mach-s5p64x0/common.c
@@ -205,6 +205,7 @@ void __init s5p64x0_init_io(struct map_desc *mach_desc, int size)
samsung_pwm_set_platdata(&s5p64x0_pwm_variant);
}
+#ifdef CONFIG_CPU_S5P6440
void __init s5p6440_map_io(void)
{
/* initialize any device information early */
@@ -218,7 +219,9 @@ void __init s5p6440_map_io(void)
iotable_init(s5p6440_iodesc, ARRAY_SIZE(s5p6440_iodesc));
}
+#endif
+#ifdef CONFIG_CPU_S5P6450
void __init s5p6450_map_io(void)
{
/* initialize any device information early */
@@ -232,13 +235,14 @@ void __init s5p6450_map_io(void)
iotable_init(s5p6450_iodesc, ARRAY_SIZE(s5p6450_iodesc));
}
+#endif
/*
* s5p64x0_init_clocks
*
* register and setup the CPU clocks
*/
-
+#ifdef CONFIG_CPU_S5P6440
void __init s5p6440_init_clocks(int xtal)
{
printk(KERN_DEBUG "%s: initializing clocks\n", __func__);
@@ -248,7 +252,9 @@ void __init s5p6440_init_clocks(int xtal)
s5p6440_register_clocks();
s5p6440_setup_clocks();
}
+#endif
+#ifdef CONFIG_CPU_S5P6450
void __init s5p6450_init_clocks(int xtal)
{
printk(KERN_DEBUG "%s: initializing clocks\n", __func__);
@@ -258,13 +264,14 @@ void __init s5p6450_init_clocks(int xtal)
s5p6450_register_clocks();
s5p6450_setup_clocks();
}
+#endif
/*
* s5p64x0_init_irq
*
* register the CPU interrupts
*/
-
+#ifdef CONFIG_CPU_S5P6440
void __init s5p6440_init_irq(void)
{
/* S5P6440 supports 2 VIC */
@@ -279,7 +286,9 @@ void __init s5p6440_init_irq(void)
s5p_init_irq(vic, ARRAY_SIZE(vic));
}
+#endif
+#ifdef CONFIG_CPU_S5P6450
void __init s5p6450_init_irq(void)
{
/* S5P6450 supports only 2 VIC */
@@ -294,6 +303,7 @@ void __init s5p6450_init_irq(void)
s5p_init_irq(vic, ARRAY_SIZE(vic));
}
+#endif
struct bus_type s5p64x0_subsys = {
.name = "s5p64x0-core",
@@ -321,6 +331,7 @@ int __init s5p64x0_init(void)
}
/* uart registration process */
+#ifdef CONFIG_CPU_S5P6440
void __init s5p6440_init_uarts(struct s3c2410_uartcfg *cfg, int no)
{
int uart;
@@ -332,11 +343,14 @@ void __init s5p6440_init_uarts(struct s3c2410_uartcfg *cfg, int no)
s3c24xx_init_uartdevs("s3c6400-uart", s5p_uart_resources, cfg, no);
}
+#endif
+#ifdef CONFIG_CPU_S5P6450
void __init s5p6450_init_uarts(struct s3c2410_uartcfg *cfg, int no)
{
s3c24xx_init_uartdevs("s3c6400-uart", s5p_uart_resources, cfg, no);
}
+#endif
#define eint_offset(irq) ((irq) - IRQ_EINT(0))
diff --git a/arch/arm/mach-s5p64x0/common.h b/arch/arm/mach-s5p64x0/common.h
index f3a9b43..cbe7f3d 100644
--- a/arch/arm/mach-s5p64x0/common.h
+++ b/arch/arm/mach-s5p64x0/common.h
@@ -25,10 +25,10 @@ void s5p6450_register_clocks(void);
void s5p6450_setup_clocks(void);
void s5p64x0_restart(enum reboot_mode mode, const char *cmd);
+extern int s5p64x0_init(void);
#ifdef CONFIG_CPU_S5P6440
-extern int s5p64x0_init(void);
extern void s5p6440_map_io(void);
extern void s5p6440_init_clocks(int xtal);
@@ -38,12 +38,10 @@ extern void s5p6440_init_uarts(struct s3c2410_uartcfg *cfg, int no);
#define s5p6440_init_clocks NULL
#define s5p6440_init_uarts NULL
#define s5p6440_map_io NULL
-#define s5p64x0_init NULL
#endif
#ifdef CONFIG_CPU_S5P6450
-extern int s5p64x0_init(void);
extern void s5p6450_map_io(void);
extern void s5p6450_init_clocks(int xtal);
@@ -53,7 +51,6 @@ extern void s5p6450_init_uarts(struct s3c2410_uartcfg *cfg, int no);
#define s5p6450_init_clocks NULL
#define s5p6450_init_uarts NULL
#define s5p6450_map_io NULL
-#define s5p64x0_init NULL
#endif
#endif /* __ARCH_ARM_MACH_S5P64X0_COMMON_H */
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 49/62] ARM: s5p64x0: fix building with only one soc type
2014-03-19 19:29 ` [PATCH 49/62] ARM: s5p64x0: fix building with only one soc type Arnd Bergmann
@ 2014-03-20 3:59 ` Kukjin Kim
0 siblings, 0 replies; 205+ messages in thread
From: Kukjin Kim @ 2014-03-20 3:59 UTC (permalink / raw)
To: linux-arm-kernel
Arnd Bergmann wrote:
>
> The s5p64x0 platform supports two distinct SoCs, s5p6440 and s5p6450,
> and in the normal configuration, both are enabled. However if we build
> a kernel that only enables one of the two, the #ifdef logic in common.c
> breaks down, as some of the functions declared in the header are defined
> to NULL using the preprocessor but then defined anyway.
>
> This patch cleans up the mess and ensures that each function has either
> exactly one C declaration and one matching C definition, or we have
> a NULL defined function pointer but no C definition.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Kukjin Kim <kgene.kim@samsung.com>
Yes you're right, we need to sort them(6440 and 6450) out later though.
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Thanks,
Kukjin
> Cc: Ben Dooks <ben-linux@fluff.org>
> ---
> arch/arm/mach-s5p64x0/common.c | 18 ++++++++++++++++--
> arch/arm/mach-s5p64x0/common.h | 5 +----
> 2 files changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-s5p64x0/common.c b/arch/arm/mach-
> s5p64x0/common.c
> index eb2ad14..9a43be0 100644
> --- a/arch/arm/mach-s5p64x0/common.c
> +++ b/arch/arm/mach-s5p64x0/common.c
> @@ -205,6 +205,7 @@ void __init s5p64x0_init_io(struct map_desc
*mach_desc,
> int size)
> samsung_pwm_set_platdata(&s5p64x0_pwm_variant);
> }
>
> +#ifdef CONFIG_CPU_S5P6440
> void __init s5p6440_map_io(void)
> {
> /* initialize any device information early */
> @@ -218,7 +219,9 @@ void __init s5p6440_map_io(void)
>
> iotable_init(s5p6440_iodesc, ARRAY_SIZE(s5p6440_iodesc));
> }
> +#endif
>
> +#ifdef CONFIG_CPU_S5P6450
> void __init s5p6450_map_io(void)
> {
> /* initialize any device information early */
> @@ -232,13 +235,14 @@ void __init s5p6450_map_io(void)
>
> iotable_init(s5p6450_iodesc, ARRAY_SIZE(s5p6450_iodesc));
> }
> +#endif
>
> /*
> * s5p64x0_init_clocks
> *
> * register and setup the CPU clocks
> */
> -
> +#ifdef CONFIG_CPU_S5P6440
> void __init s5p6440_init_clocks(int xtal)
> {
> printk(KERN_DEBUG "%s: initializing clocks\n", __func__);
> @@ -248,7 +252,9 @@ void __init s5p6440_init_clocks(int xtal)
> s5p6440_register_clocks();
> s5p6440_setup_clocks();
> }
> +#endif
>
> +#ifdef CONFIG_CPU_S5P6450
> void __init s5p6450_init_clocks(int xtal)
> {
> printk(KERN_DEBUG "%s: initializing clocks\n", __func__);
> @@ -258,13 +264,14 @@ void __init s5p6450_init_clocks(int xtal)
> s5p6450_register_clocks();
> s5p6450_setup_clocks();
> }
> +#endif
>
> /*
> * s5p64x0_init_irq
> *
> * register the CPU interrupts
> */
> -
> +#ifdef CONFIG_CPU_S5P6440
> void __init s5p6440_init_irq(void)
> {
> /* S5P6440 supports 2 VIC */
> @@ -279,7 +286,9 @@ void __init s5p6440_init_irq(void)
>
> s5p_init_irq(vic, ARRAY_SIZE(vic));
> }
> +#endif
>
> +#ifdef CONFIG_CPU_S5P6450
> void __init s5p6450_init_irq(void)
> {
> /* S5P6450 supports only 2 VIC */
> @@ -294,6 +303,7 @@ void __init s5p6450_init_irq(void)
>
> s5p_init_irq(vic, ARRAY_SIZE(vic));
> }
> +#endif
>
> struct bus_type s5p64x0_subsys = {
> .name = "s5p64x0-core",
> @@ -321,6 +331,7 @@ int __init s5p64x0_init(void)
> }
>
> /* uart registration process */
> +#ifdef CONFIG_CPU_S5P6440
> void __init s5p6440_init_uarts(struct s3c2410_uartcfg *cfg, int no)
> {
> int uart;
> @@ -332,11 +343,14 @@ void __init s5p6440_init_uarts(struct
> s3c2410_uartcfg *cfg, int no)
>
> s3c24xx_init_uartdevs("s3c6400-uart", s5p_uart_resources, cfg, no);
> }
> +#endif
>
> +#ifdef CONFIG_CPU_S5P6450
> void __init s5p6450_init_uarts(struct s3c2410_uartcfg *cfg, int no)
> {
> s3c24xx_init_uartdevs("s3c6400-uart", s5p_uart_resources, cfg, no);
> }
> +#endif
>
> #define eint_offset(irq) ((irq) - IRQ_EINT(0))
>
> diff --git a/arch/arm/mach-s5p64x0/common.h b/arch/arm/mach-
> s5p64x0/common.h
> index f3a9b43..cbe7f3d 100644
> --- a/arch/arm/mach-s5p64x0/common.h
> +++ b/arch/arm/mach-s5p64x0/common.h
> @@ -25,10 +25,10 @@ void s5p6450_register_clocks(void);
> void s5p6450_setup_clocks(void);
>
> void s5p64x0_restart(enum reboot_mode mode, const char *cmd);
> +extern int s5p64x0_init(void);
>
> #ifdef CONFIG_CPU_S5P6440
>
> -extern int s5p64x0_init(void);
> extern void s5p6440_map_io(void);
> extern void s5p6440_init_clocks(int xtal);
>
> @@ -38,12 +38,10 @@ extern void s5p6440_init_uarts(struct s3c2410_uartcfg
> *cfg, int no);
> #define s5p6440_init_clocks NULL
> #define s5p6440_init_uarts NULL
> #define s5p6440_map_io NULL
> -#define s5p64x0_init NULL
> #endif
>
> #ifdef CONFIG_CPU_S5P6450
>
> -extern int s5p64x0_init(void);
> extern void s5p6450_map_io(void);
> extern void s5p6450_init_clocks(int xtal);
>
> @@ -53,7 +51,6 @@ extern void s5p6450_init_uarts(struct s3c2410_uartcfg
> *cfg, int no);
> #define s5p6450_init_clocks NULL
> #define s5p6450_init_uarts NULL
> #define s5p6450_map_io NULL
> -#define s5p64x0_init NULL
> #endif
>
> #endif /* __ARCH_ARM_MACH_S5P64X0_COMMON_H */
> --
> 1.8.3.2
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 50/62] ARM: s5pv210: enable IDE support in MACH_TORBRECK
2014-03-19 19:28 ` Arnd Bergmann
` (49 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-20 4:01 ` Kukjin Kim
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
Building MACH_TORBRECK by itself results in a build error
because we try to reference the s3c_device_cfcon definition
that is hidden inside CONFIG_SAMSUNG_DEV_IDE. This changes
the Kconfig logic to ensure that option is enabled when we
need it.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
arch/arm/mach-s5pv210/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig
index caaedaf..8c3abe5 100644
--- a/arch/arm/mach-s5pv210/Kconfig
+++ b/arch/arm/mach-s5pv210/Kconfig
@@ -189,6 +189,7 @@ config MACH_TORBRECK
select S5PV210_SETUP_I2C1
select S5PV210_SETUP_I2C2
select S5PV210_SETUP_SDHCI
+ select SAMSUNG_DEV_IDE
help
Machine support for aESOP Torbreck
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 50/62] ARM: s5pv210: enable IDE support in MACH_TORBRECK
2014-03-19 19:29 ` [PATCH 50/62] ARM: s5pv210: enable IDE support in MACH_TORBRECK Arnd Bergmann
@ 2014-03-20 4:01 ` Kukjin Kim
0 siblings, 0 replies; 205+ messages in thread
From: Kukjin Kim @ 2014-03-20 4:01 UTC (permalink / raw)
To: linux-arm-kernel
Arnd Bergmann wrote:
>
> Building MACH_TORBRECK by itself results in a build error
> because we try to reference the s3c_device_cfcon definition
> that is hidden inside CONFIG_SAMSUNG_DEV_IDE. This changes
> the Kconfig logic to ensure that option is enabled when we
> need it.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Kukjin Kim <kgene.kim@samsung.com>
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Thanks,
Kukjin
> Cc: Ben Dooks <ben-linux@fluff.org>
> ---
> arch/arm/mach-s5pv210/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig
> index caaedaf..8c3abe5 100644
> --- a/arch/arm/mach-s5pv210/Kconfig
> +++ b/arch/arm/mach-s5pv210/Kconfig
> @@ -189,6 +189,7 @@ config MACH_TORBRECK
> select S5PV210_SETUP_I2C1
> select S5PV210_SETUP_I2C2
> select S5PV210_SETUP_SDHCI
> + select SAMSUNG_DEV_IDE
> help
> Machine support for aESOP Torbreck
>
> --
> 1.8.3.2
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 51/62] ARM: samsung: allow serial driver to be disabled
2014-03-19 19:28 ` Arnd Bergmann
` (50 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-20 4:03 ` Kukjin Kim
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
If CONFIG_SERIAL_SAMSUNG is disabled, we run into build errors
with some samsung platforms. This adds a couple of #ifdef
statements to hopefully deal with this more gracefully.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
arch/arm/mach-s3c64xx/irq-pm.c | 12 +++++++++---
arch/arm/mach-s5p64x0/irq-pm.c | 6 ++++++
arch/arm/plat-samsung/init.c | 4 ++++
3 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-s3c64xx/irq-pm.c b/arch/arm/mach-s3c64xx/irq-pm.c
index a61247b..ae4ea76 100644
--- a/arch/arm/mach-s3c64xx/irq-pm.c
+++ b/arch/arm/mach-s3c64xx/irq-pm.c
@@ -55,7 +55,13 @@ static struct irq_grp_save {
u32 mask;
} eint_grp_save[5];
-static u32 irq_uart_mask[CONFIG_SERIAL_SAMSUNG_UARTS];
+#ifndef CONFIG_SERIAL_SAMSUNG_UARTS
+#define SERIAL_SAMSUNG_UARTS 0
+#else
+#define SERIAL_SAMSUNG_UARTS CONFIG_SERIAL_SAMSUNG_UARTS
+#endif
+
+static u32 irq_uart_mask[SERIAL_SAMSUNG_UARTS];
static int s3c64xx_irq_pm_suspend(void)
{
@@ -66,7 +72,7 @@ static int s3c64xx_irq_pm_suspend(void)
s3c_pm_do_save(irq_save, ARRAY_SIZE(irq_save));
- for (i = 0; i < CONFIG_SERIAL_SAMSUNG_UARTS; i++)
+ for (i = 0; i < SERIAL_SAMSUNG_UARTS; i++)
irq_uart_mask[i] = __raw_readl(S3C_VA_UARTx(i) + S3C64XX_UINTM);
for (i = 0; i < ARRAY_SIZE(eint_grp_save); i++, grp++) {
@@ -87,7 +93,7 @@ static void s3c64xx_irq_pm_resume(void)
s3c_pm_do_restore(irq_save, ARRAY_SIZE(irq_save));
- for (i = 0; i < CONFIG_SERIAL_SAMSUNG_UARTS; i++)
+ for (i = 0; i < SERIAL_SAMSUNG_UARTS; i++)
__raw_writel(irq_uart_mask[i], S3C_VA_UARTx(i) + S3C64XX_UINTM);
for (i = 0; i < ARRAY_SIZE(eint_grp_save); i++, grp++) {
diff --git a/arch/arm/mach-s5p64x0/irq-pm.c b/arch/arm/mach-s5p64x0/irq-pm.c
index 1c83d28..2ed921e 100644
--- a/arch/arm/mach-s5p64x0/irq-pm.c
+++ b/arch/arm/mach-s5p64x0/irq-pm.c
@@ -34,7 +34,9 @@ static struct irq_grp_save {
u32 mask;
} eint_grp_save[4];
+#ifdef CONFIG_SERIAL_SAMSUNG
static u32 irq_uart_mask[CONFIG_SERIAL_SAMSUNG_UARTS];
+#endif
static int s5p64x0_irq_pm_suspend(void)
{
@@ -45,8 +47,10 @@ static int s5p64x0_irq_pm_suspend(void)
s3c_pm_do_save(irq_save, ARRAY_SIZE(irq_save));
+#ifdef CONFIG_SERIAL_SAMSUNG
for (i = 0; i < CONFIG_SERIAL_SAMSUNG_UARTS; i++)
irq_uart_mask[i] = __raw_readl(S3C_VA_UARTx(i) + S3C64XX_UINTM);
+#endif
for (i = 0; i < ARRAY_SIZE(eint_grp_save); i++, grp++) {
grp->con = __raw_readl(S5P64X0_EINT12CON + (i * 4));
@@ -66,8 +70,10 @@ static void s5p64x0_irq_pm_resume(void)
s3c_pm_do_restore(irq_save, ARRAY_SIZE(irq_save));
+#ifdef CONFIG_SERIAL_SAMSUNG
for (i = 0; i < CONFIG_SERIAL_SAMSUNG_UARTS; i++)
__raw_writel(irq_uart_mask[i], S3C_VA_UARTx(i) + S3C64XX_UINTM);
+#endif
for (i = 0; i < ARRAY_SIZE(eint_grp_save); i++, grp++) {
__raw_writel(grp->con, S5P64X0_EINT12CON + (i * 4));
diff --git a/arch/arm/plat-samsung/init.c b/arch/arm/plat-samsung/init.c
index 0ffc84a..c32df1f 100644
--- a/arch/arm/plat-samsung/init.c
+++ b/arch/arm/plat-samsung/init.c
@@ -96,7 +96,9 @@ void __init s3c24xx_init_clocks(int xtal)
#if IS_ENABLED(CONFIG_SAMSUNG_ATAGS)
static int nr_uarts __initdata = 0;
+#ifdef CONFIG_SERIAL_SAMSUNG_UARTS
static struct s3c2410_uartcfg uart_cfgs[CONFIG_SERIAL_SAMSUNG_UARTS];
+#endif
/* s3c24xx_init_uartdevs
*
@@ -111,6 +113,7 @@ void __init s3c24xx_init_uartdevs(char *name,
struct s3c24xx_uart_resources *res,
struct s3c2410_uartcfg *cfg, int no)
{
+#ifdef CONFIG_SERIAL_SAMSUNG_UARTS
struct platform_device *platdev;
struct s3c2410_uartcfg *cfgptr = uart_cfgs;
struct s3c24xx_uart_resources *resp;
@@ -133,6 +136,7 @@ void __init s3c24xx_init_uartdevs(char *name,
}
nr_uarts = no;
+#endif
}
void __init s3c24xx_init_uarts(struct s3c2410_uartcfg *cfg, int no)
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 51/62] ARM: samsung: allow serial driver to be disabled
2014-03-19 19:29 ` [PATCH 51/62] ARM: samsung: allow serial driver to be disabled Arnd Bergmann
@ 2014-03-20 4:03 ` Kukjin Kim
0 siblings, 0 replies; 205+ messages in thread
From: Kukjin Kim @ 2014-03-20 4:03 UTC (permalink / raw)
To: linux-arm-kernel
Arnd Bergmann wrote:
>
> If CONFIG_SERIAL_SAMSUNG is disabled, we run into build errors
> with some samsung platforms. This adds a couple of #ifdef
> statements to hopefully deal with this more gracefully.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Kukjin Kim <kgene.kim@samsung.com>
Looks good to me,
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Thanks,
Kukjin
> Cc: Ben Dooks <ben-linux@fluff.org>
> ---
> arch/arm/mach-s3c64xx/irq-pm.c | 12 +++++++++---
> arch/arm/mach-s5p64x0/irq-pm.c | 6 ++++++
> arch/arm/plat-samsung/init.c | 4 ++++
> 3 files changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-s3c64xx/irq-pm.c b/arch/arm/mach-s3c64xx/irq-
> pm.c
> index a61247b..ae4ea76 100644
> --- a/arch/arm/mach-s3c64xx/irq-pm.c
> +++ b/arch/arm/mach-s3c64xx/irq-pm.c
> @@ -55,7 +55,13 @@ static struct irq_grp_save {
> u32 mask;
> } eint_grp_save[5];
>
> -static u32 irq_uart_mask[CONFIG_SERIAL_SAMSUNG_UARTS];
> +#ifndef CONFIG_SERIAL_SAMSUNG_UARTS
> +#define SERIAL_SAMSUNG_UARTS 0
> +#else
> +#define SERIAL_SAMSUNG_UARTS CONFIG_SERIAL_SAMSUNG_UARTS
> +#endif
> +
> +static u32 irq_uart_mask[SERIAL_SAMSUNG_UARTS];
>
> static int s3c64xx_irq_pm_suspend(void)
> {
> @@ -66,7 +72,7 @@ static int s3c64xx_irq_pm_suspend(void)
>
> s3c_pm_do_save(irq_save, ARRAY_SIZE(irq_save));
>
> - for (i = 0; i < CONFIG_SERIAL_SAMSUNG_UARTS; i++)
> + for (i = 0; i < SERIAL_SAMSUNG_UARTS; i++)
> irq_uart_mask[i] = __raw_readl(S3C_VA_UARTx(i) +
> S3C64XX_UINTM);
>
> for (i = 0; i < ARRAY_SIZE(eint_grp_save); i++, grp++) {
> @@ -87,7 +93,7 @@ static void s3c64xx_irq_pm_resume(void)
>
> s3c_pm_do_restore(irq_save, ARRAY_SIZE(irq_save));
>
> - for (i = 0; i < CONFIG_SERIAL_SAMSUNG_UARTS; i++)
> + for (i = 0; i < SERIAL_SAMSUNG_UARTS; i++)
> __raw_writel(irq_uart_mask[i], S3C_VA_UARTx(i) +
> S3C64XX_UINTM);
>
> for (i = 0; i < ARRAY_SIZE(eint_grp_save); i++, grp++) {
> diff --git a/arch/arm/mach-s5p64x0/irq-pm.c b/arch/arm/mach-s5p64x0/irq-
> pm.c
> index 1c83d28..2ed921e 100644
> --- a/arch/arm/mach-s5p64x0/irq-pm.c
> +++ b/arch/arm/mach-s5p64x0/irq-pm.c
> @@ -34,7 +34,9 @@ static struct irq_grp_save {
> u32 mask;
> } eint_grp_save[4];
>
> +#ifdef CONFIG_SERIAL_SAMSUNG
> static u32 irq_uart_mask[CONFIG_SERIAL_SAMSUNG_UARTS];
> +#endif
>
> static int s5p64x0_irq_pm_suspend(void)
> {
> @@ -45,8 +47,10 @@ static int s5p64x0_irq_pm_suspend(void)
>
> s3c_pm_do_save(irq_save, ARRAY_SIZE(irq_save));
>
> +#ifdef CONFIG_SERIAL_SAMSUNG
> for (i = 0; i < CONFIG_SERIAL_SAMSUNG_UARTS; i++)
> irq_uart_mask[i] = __raw_readl(S3C_VA_UARTx(i) +
> S3C64XX_UINTM);
> +#endif
>
> for (i = 0; i < ARRAY_SIZE(eint_grp_save); i++, grp++) {
> grp->con = __raw_readl(S5P64X0_EINT12CON + (i * 4));
> @@ -66,8 +70,10 @@ static void s5p64x0_irq_pm_resume(void)
>
> s3c_pm_do_restore(irq_save, ARRAY_SIZE(irq_save));
>
> +#ifdef CONFIG_SERIAL_SAMSUNG
> for (i = 0; i < CONFIG_SERIAL_SAMSUNG_UARTS; i++)
> __raw_writel(irq_uart_mask[i], S3C_VA_UARTx(i) +
> S3C64XX_UINTM);
> +#endif
>
> for (i = 0; i < ARRAY_SIZE(eint_grp_save); i++, grp++) {
> __raw_writel(grp->con, S5P64X0_EINT12CON + (i * 4));
> diff --git a/arch/arm/plat-samsung/init.c b/arch/arm/plat-samsung/init.c
> index 0ffc84a..c32df1f 100644
> --- a/arch/arm/plat-samsung/init.c
> +++ b/arch/arm/plat-samsung/init.c
> @@ -96,7 +96,9 @@ void __init s3c24xx_init_clocks(int xtal)
> #if IS_ENABLED(CONFIG_SAMSUNG_ATAGS)
> static int nr_uarts __initdata = 0;
>
> +#ifdef CONFIG_SERIAL_SAMSUNG_UARTS
> static struct s3c2410_uartcfg uart_cfgs[CONFIG_SERIAL_SAMSUNG_UARTS];
> +#endif
>
> /* s3c24xx_init_uartdevs
> *
> @@ -111,6 +113,7 @@ void __init s3c24xx_init_uartdevs(char *name,
> struct s3c24xx_uart_resources *res,
> struct s3c2410_uartcfg *cfg, int no)
> {
> +#ifdef CONFIG_SERIAL_SAMSUNG_UARTS
> struct platform_device *platdev;
> struct s3c2410_uartcfg *cfgptr = uart_cfgs;
> struct s3c24xx_uart_resources *resp;
> @@ -133,6 +136,7 @@ void __init s3c24xx_init_uartdevs(char *name,
> }
>
> nr_uarts = no;
> +#endif
> }
>
> void __init s3c24xx_init_uarts(struct s3c2410_uartcfg *cfg, int no)
> --
> 1.8.3.2
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 52/62] ARM: samsung: disable decompressor watchdog on exynos
2014-03-19 19:28 ` Arnd Bergmann
` (51 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-20 4:11 ` Kukjin Kim
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
The S3C_BOOT_ERROR_RESET option only works when using the
samsung specific mach/uncompress.h implementation. The
Exynos platform has now moved on to using the generic
implementation instead, which does not support this.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
arch/arm/plat-samsung/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index 58645a5..04974db 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -42,6 +42,7 @@ comment "Boot options"
config S3C_BOOT_ERROR_RESET
bool "S3C Reboot on decompression error"
+ depends on PLAT_S5P || PLAT_S3C24XX || ARCH_S3C64XX
help
Say y here to use the watchdog to reset the system if the
kernel decompressor detects an error during decompression.
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 52/62] ARM: samsung: disable decompressor watchdog on exynos
2014-03-19 19:29 ` [PATCH 52/62] ARM: samsung: disable decompressor watchdog on exynos Arnd Bergmann
@ 2014-03-20 4:11 ` Kukjin Kim
2014-03-21 16:14 ` Arnd Bergmann
0 siblings, 1 reply; 205+ messages in thread
From: Kukjin Kim @ 2014-03-20 4:11 UTC (permalink / raw)
To: linux-arm-kernel
Arnd Bergmann wrote:
>
> The S3C_BOOT_ERROR_RESET option only works when using the
> samsung specific mach/uncompress.h implementation. The
> Exynos platform has now moved on to using the generic
> implementation instead, which does not support this.
>
Yeah, correct and I've applied to use the generic uncompress for other
Samsung SoCs into samsung tree and I sent to arm-soc a couple of days ago.
Even though it is not cleaned for regarding configs e.g.,
S3C_BOOT_ERROR_RESET yet, this is not used more.
Thanks,
Kukjin
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Kukjin Kim <kgene.kim@samsung.com>
> Cc: Ben Dooks <ben-linux@fluff.org>
> ---
> arch/arm/plat-samsung/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
> index 58645a5..04974db 100644
> --- a/arch/arm/plat-samsung/Kconfig
> +++ b/arch/arm/plat-samsung/Kconfig
> @@ -42,6 +42,7 @@ comment "Boot options"
>
> config S3C_BOOT_ERROR_RESET
> bool "S3C Reboot on decompression error"
> + depends on PLAT_S5P || PLAT_S3C24XX || ARCH_S3C64XX
> help
> Say y here to use the watchdog to reset the system if the
> kernel decompressor detects an error during decompression.
> --
> 1.8.3.2
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 52/62] ARM: samsung: disable decompressor watchdog on exynos
2014-03-20 4:11 ` Kukjin Kim
@ 2014-03-21 16:14 ` Arnd Bergmann
2014-03-21 23:41 ` Kukjin Kim
0 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-21 16:14 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 20 March 2014, Kukjin Kim wrote:
> Arnd Bergmann wrote:
> >
> > The S3C_BOOT_ERROR_RESET option only works when using the
> > samsung specific mach/uncompress.h implementation. The
> > Exynos platform has now moved on to using the generic
> > implementation instead, which does not support this.
> >
> Yeah, correct and I've applied to use the generic uncompress for other
> Samsung SoCs into samsung tree and I sent to arm-soc a couple of days ago.
> Even though it is not cleaned for regarding configs e.g.,
> S3C_BOOT_ERROR_RESET yet, this is not used more.
>
Ok, dropping my patch for now.
Arnd
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 52/62] ARM: samsung: disable decompressor watchdog on exynos
2014-03-21 16:14 ` Arnd Bergmann
@ 2014-03-21 23:41 ` Kukjin Kim
0 siblings, 0 replies; 205+ messages in thread
From: Kukjin Kim @ 2014-03-21 23:41 UTC (permalink / raw)
To: linux-arm-kernel
Arnd Bergmann wrote:
>
> On Thursday 20 March 2014, Kukjin Kim wrote:
> > Arnd Bergmann wrote:
> > >
> > > The S3C_BOOT_ERROR_RESET option only works when using the
> > > samsung specific mach/uncompress.h implementation. The
> > > Exynos platform has now moved on to using the generic
> > > implementation instead, which does not support this.
> > >
> > Yeah, correct and I've applied to use the generic uncompress for other
> > Samsung SoCs into samsung tree and I sent to arm-soc a couple of days ago.
> > Even though it is not cleaned for regarding configs e.g.,
> > S3C_BOOT_ERROR_RESET yet, this is not used more.
> >
>
> Ok, dropping my patch for now.
>
Thanks,
Kukjin
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 53/62] ARM: samsung: fix SAMSUNG_PM_DEBUG Kconfig logic
2014-03-19 19:28 ` Arnd Bergmann
` (52 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-20 4:13 ` Kukjin Kim
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
The suspend debug code for Samsung has multiple dependencies
that we should not unconditionally enable. In particular,
we rely on the DEBUG_S3C_UART setting, which in turn depends
on the samsung UART driver.
Signed-off-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
arch/arm/plat-samsung/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index 04974db..c72d612 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -428,8 +428,7 @@ comment "Power management"
config SAMSUNG_PM_DEBUG
bool "S3C2410 PM Suspend debug"
- depends on PM
- select DEBUG_LL
+ depends on PM && DEBUG_KERNEL && DEBUG_S3C_UART
help
Say Y here if you want verbose debugging from the PM Suspend and
Resume code. See <file:Documentation/arm/Samsung-S3C24XX/Suspend.txt>
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 53/62] ARM: samsung: fix SAMSUNG_PM_DEBUG Kconfig logic
2014-03-19 19:29 ` [PATCH 53/62] ARM: samsung: fix SAMSUNG_PM_DEBUG Kconfig logic Arnd Bergmann
@ 2014-03-20 4:13 ` Kukjin Kim
0 siblings, 0 replies; 205+ messages in thread
From: Kukjin Kim @ 2014-03-20 4:13 UTC (permalink / raw)
To: linux-arm-kernel
Arnd Bergmann wrote:
>
> The suspend debug code for Samsung has multiple dependencies
> that we should not unconditionally enable. In particular,
> we rely on the DEBUG_S3C_UART setting, which in turn depends
> on the samsung UART driver.
>
> Signed-off-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Kukjin Kim <kgene.kim@samsung.com>
Yes, right.
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Thanks,
Kukjin
> Cc: Ben Dooks <ben-linux@fluff.org>
> ---
> arch/arm/plat-samsung/Kconfig | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
> index 04974db..c72d612 100644
> --- a/arch/arm/plat-samsung/Kconfig
> +++ b/arch/arm/plat-samsung/Kconfig
> @@ -428,8 +428,7 @@ comment "Power management"
>
> config SAMSUNG_PM_DEBUG
> bool "S3C2410 PM Suspend debug"
> - depends on PM
> - select DEBUG_LL
> + depends on PM && DEBUG_KERNEL && DEBUG_S3C_UART
> help
> Say Y here if you want verbose debugging from the PM Suspend and
> Resume code. See <file:Documentation/arm/Samsung-
> S3C24XX/Suspend.txt>
> --
> 1.8.3.2
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 54/62] ARM: samsung: select ATAGS where necessary
2014-03-19 19:28 ` Arnd Bergmann
` (53 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-20 4:14 ` Kukjin Kim
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
Most of the Samsung platforms do not yet allow building with
DT at all, so we should select CONFIG_ATAGS for now in all
cases we also select CONFIG_SAMSUNG_ATAGS.
Found during randconfig testing.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
arch/arm/Kconfig | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6ffcadd..3fb9b7e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -731,6 +731,7 @@ config ARCH_S3C24XX
bool "Samsung S3C24XX SoCs"
select ARCH_HAS_CPUFREQ
select ARCH_REQUIRE_GPIOLIB
+ select ATAGS
select CLKDEV_LOOKUP
select CLKSRC_SAMSUNG_PWM
select GENERIC_CLOCKEVENTS
@@ -753,6 +754,7 @@ config ARCH_S3C64XX
select ARCH_REQUIRE_GPIOLIB
select ARM_AMBA
select ARM_VIC
+ select ATAGS
select CLKDEV_LOOKUP
select CLKSRC_SAMSUNG_PWM
select COMMON_CLK
@@ -776,6 +778,7 @@ config ARCH_S3C64XX
config ARCH_S5P64X0
bool "Samsung S5P6440 S5P6450"
+ select ATAGS
select CLKDEV_LOOKUP
select CLKSRC_SAMSUNG_PWM
select CPU_V6
@@ -794,6 +797,7 @@ config ARCH_S5P64X0
config ARCH_S5PC100
bool "Samsung S5PC100"
select ARCH_REQUIRE_GPIOLIB
+ select ATAGS
select CLKDEV_LOOKUP
select CLKSRC_SAMSUNG_PWM
select CPU_V7
@@ -813,6 +817,7 @@ config ARCH_S5PV210
select ARCH_HAS_CPUFREQ
select ARCH_HAS_HOLES_MEMORYMODEL
select ARCH_SPARSEMEM_ENABLE
+ select ATAGS
select CLKDEV_LOOKUP
select CLKSRC_SAMSUNG_PWM
select CPU_V7
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 54/62] ARM: samsung: select ATAGS where necessary
2014-03-19 19:29 ` [PATCH 54/62] ARM: samsung: select ATAGS where necessary Arnd Bergmann
@ 2014-03-20 4:14 ` Kukjin Kim
0 siblings, 0 replies; 205+ messages in thread
From: Kukjin Kim @ 2014-03-20 4:14 UTC (permalink / raw)
To: linux-arm-kernel
Arnd Bergmann wrote:
>
> Most of the Samsung platforms do not yet allow building with
> DT at all, so we should select CONFIG_ATAGS for now in all
> cases we also select CONFIG_SAMSUNG_ATAGS.
>
> Found during randconfig testing.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Kukjin Kim <kgene.kim@samsung.com>
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Thanks,
Kukjin
> Cc: Ben Dooks <ben-linux@fluff.org>
> ---
> arch/arm/Kconfig | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 6ffcadd..3fb9b7e 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -731,6 +731,7 @@ config ARCH_S3C24XX
> bool "Samsung S3C24XX SoCs"
> select ARCH_HAS_CPUFREQ
> select ARCH_REQUIRE_GPIOLIB
> + select ATAGS
> select CLKDEV_LOOKUP
> select CLKSRC_SAMSUNG_PWM
> select GENERIC_CLOCKEVENTS
> @@ -753,6 +754,7 @@ config ARCH_S3C64XX
> select ARCH_REQUIRE_GPIOLIB
> select ARM_AMBA
> select ARM_VIC
> + select ATAGS
> select CLKDEV_LOOKUP
> select CLKSRC_SAMSUNG_PWM
> select COMMON_CLK
> @@ -776,6 +778,7 @@ config ARCH_S3C64XX
>
> config ARCH_S5P64X0
> bool "Samsung S5P6440 S5P6450"
> + select ATAGS
> select CLKDEV_LOOKUP
> select CLKSRC_SAMSUNG_PWM
> select CPU_V6
> @@ -794,6 +797,7 @@ config ARCH_S5P64X0
> config ARCH_S5PC100
> bool "Samsung S5PC100"
> select ARCH_REQUIRE_GPIOLIB
> + select ATAGS
> select CLKDEV_LOOKUP
> select CLKSRC_SAMSUNG_PWM
> select CPU_V7
> @@ -813,6 +817,7 @@ config ARCH_S5PV210
> select ARCH_HAS_CPUFREQ
> select ARCH_HAS_HOLES_MEMORYMODEL
> select ARCH_SPARSEMEM_ENABLE
> + select ATAGS
> select CLKDEV_LOOKUP
> select CLKSRC_SAMSUNG_PWM
> select CPU_V7
> --
> 1.8.3.2
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 55/62] ARM: samsung: select CRC32 for SAMSUNG_PM_CHECK
2014-03-19 19:28 ` Arnd Bergmann
` (54 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-20 4:16 ` Kukjin Kim
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
The Samsung pm_check code uses the crc32 library code, which can
be built as a loadable module, in which case we get a link error
building the kernel.
A better solution is to use 'select CRC32', which is what all
other users of this code do, as it ensures it is always built-in.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
arch/arm/plat-samsung/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index c72d612..98f223c 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -445,7 +445,8 @@ config S3C_PM_DEBUG_LED_SMDK
config SAMSUNG_PM_CHECK
bool "S3C2410 PM Suspend Memory CRC"
- depends on PM && CRC32
+ depends on PM
+ select CRC32
help
Enable the PM code's memory area checksum over sleep. This option
will generate CRCs of all blocks of memory, and store them before
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 55/62] ARM: samsung: select CRC32 for SAMSUNG_PM_CHECK
2014-03-19 19:29 ` [PATCH 55/62] ARM: samsung: select CRC32 for SAMSUNG_PM_CHECK Arnd Bergmann
@ 2014-03-20 4:16 ` Kukjin Kim
0 siblings, 0 replies; 205+ messages in thread
From: Kukjin Kim @ 2014-03-20 4:16 UTC (permalink / raw)
To: linux-arm-kernel
Arnd Bergmann wrote:
>
> The Samsung pm_check code uses the crc32 library code, which can
> be built as a loadable module, in which case we get a link error
> building the kernel.
>
> A better solution is to use 'select CRC32', which is what all
> other users of this code do, as it ensures it is always built-in.
>
Agreed.
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Kukjin Kim <kgene.kim@samsung.com>
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Thanks,
Kukjin
> Cc: Ben Dooks <ben-linux@fluff.org>
> ---
> arch/arm/plat-samsung/Kconfig | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
> index c72d612..98f223c 100644
> --- a/arch/arm/plat-samsung/Kconfig
> +++ b/arch/arm/plat-samsung/Kconfig
> @@ -445,7 +445,8 @@ config S3C_PM_DEBUG_LED_SMDK
>
> config SAMSUNG_PM_CHECK
> bool "S3C2410 PM Suspend Memory CRC"
> - depends on PM && CRC32
> + depends on PM
> + select CRC32
> help
> Enable the PM code's memory area checksum over sleep. This option
> will generate CRCs of all blocks of memory, and store them before
> --
> 1.8.3.2
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 56/62] ARM: samsung: select I2C where needed for PMIC
2014-03-19 19:28 ` Arnd Bergmann
` (55 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-20 4:18 ` Kukjin Kim
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
The OSIRIS machine cannot build without I2C and
TPS65010 both enabled unconditionally.
The SMDK6410_WM1190_EV1 and SMDK6410_WM1192_EV1 add-on
cards already select MFD_WM*_I2C.
In each case, failing to enable CONFIG_I2C results in a
build or link error, so most consistent solution is to
ensure that it is impossible to disable those options.
It would be nice to leave CONFIG_I2C as user-selectable,
but doing that properly would require more work.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
arch/arm/mach-s3c24xx/Kconfig | 1 +
arch/arm/mach-s3c64xx/Kconfig | 2 ++
2 files changed, 3 insertions(+)
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index a6060d0..1272647 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -572,6 +572,7 @@ config MACH_OSIRIS_DVS
tristate "Simtec IM2440D20 (OSIRIS) Dynamic Voltage Scaling driver"
depends on MACH_OSIRIS
select TPS65010
+ select I2C
help
Say Y/M here if you want to have dynamic voltage scaling support
on the Simtec IM2440D20 (OSIRIS) module via the TPS65011.
diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
index 92885d7..0148112 100644
--- a/arch/arm/mach-s3c64xx/Kconfig
+++ b/arch/arm/mach-s3c64xx/Kconfig
@@ -191,6 +191,7 @@ endchoice
config SMDK6410_WM1190_EV1
bool "Support Wolfson Microelectronics 1190-EV1 PMIC card"
depends on MACH_SMDK6410
+ select I2C
select MFD_WM8350_I2C
select REGULATOR
select REGULATOR_WM8350
@@ -205,6 +206,7 @@ config SMDK6410_WM1190_EV1
config SMDK6410_WM1192_EV1
bool "Support Wolfson Microelectronics 1192-EV1 PMIC card"
depends on MACH_SMDK6410
+ select I2C
select MFD_WM831X
select MFD_WM831X_I2C
select REGULATOR
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 56/62] ARM: samsung: select I2C where needed for PMIC
2014-03-19 19:29 ` [PATCH 56/62] ARM: samsung: select I2C where needed for PMIC Arnd Bergmann
@ 2014-03-20 4:18 ` Kukjin Kim
0 siblings, 0 replies; 205+ messages in thread
From: Kukjin Kim @ 2014-03-20 4:18 UTC (permalink / raw)
To: linux-arm-kernel
Arnd Bergmann wrote:
>
> The OSIRIS machine cannot build without I2C and
> TPS65010 both enabled unconditionally.
>
> The SMDK6410_WM1190_EV1 and SMDK6410_WM1192_EV1 add-on
> cards already select MFD_WM*_I2C.
>
> In each case, failing to enable CONFIG_I2C results in a
> build or link error, so most consistent solution is to
> ensure that it is impossible to disable those options.
>
> It would be nice to leave CONFIG_I2C as user-selectable,
> but doing that properly would require more work.
>
Yes, OK.
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Kukjin Kim <kgene.kim@samsung.com>
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Thanks,
Kukjin
> Cc: Ben Dooks <ben-linux@fluff.org>
> ---
> arch/arm/mach-s3c24xx/Kconfig | 1 +
> arch/arm/mach-s3c64xx/Kconfig | 2 ++
> 2 files changed, 3 insertions(+)
>
> diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
> index a6060d0..1272647 100644
> --- a/arch/arm/mach-s3c24xx/Kconfig
> +++ b/arch/arm/mach-s3c24xx/Kconfig
> @@ -572,6 +572,7 @@ config MACH_OSIRIS_DVS
> tristate "Simtec IM2440D20 (OSIRIS) Dynamic Voltage Scaling driver"
> depends on MACH_OSIRIS
> select TPS65010
> + select I2C
> help
> Say Y/M here if you want to have dynamic voltage scaling support
> on the Simtec IM2440D20 (OSIRIS) module via the TPS65011.
> diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
> index 92885d7..0148112 100644
> --- a/arch/arm/mach-s3c64xx/Kconfig
> +++ b/arch/arm/mach-s3c64xx/Kconfig
> @@ -191,6 +191,7 @@ endchoice
> config SMDK6410_WM1190_EV1
> bool "Support Wolfson Microelectronics 1190-EV1 PMIC card"
> depends on MACH_SMDK6410
> + select I2C
> select MFD_WM8350_I2C
> select REGULATOR
> select REGULATOR_WM8350
> @@ -205,6 +206,7 @@ config SMDK6410_WM1190_EV1
> config SMDK6410_WM1192_EV1
> bool "Support Wolfson Microelectronics 1192-EV1 PMIC card"
> depends on MACH_SMDK6410
> + select I2C
> select MFD_WM831X
> select MFD_WM831X_I2C
> select REGULATOR
> --
> 1.8.3.2
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 57/62] ARM: exynos: fix l2x0 saved regs handling
2014-03-19 19:28 ` Arnd Bergmann
` (56 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-20 4:19 ` Kukjin Kim
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
The exynos4_l2x0_cache_init function tries to flush the data cache
for the location of the saved l2x0 registers and pass the physical
address to the s5p-sleep implementation.
However, the s5p-sleep code is optional, and if it is disabled,
we get a linker error here when the l2x0_regs_phys variable does
not exist.
To solve this, use a compile-time conditional to drop this code
if we don't want it.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
arch/arm/mach-exynos/common.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 025fd82..b2f9bb0 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -404,8 +404,10 @@ static int __init exynos4_l2x0_cache_init(void)
if (ret)
return ret;
- l2x0_regs_phys = virt_to_phys(&l2x0_saved_regs);
- clean_dcache_area(&l2x0_regs_phys, sizeof(unsigned long));
+ if (IS_ENABLED(CONFIG_S5P_SLEEP)) {
+ l2x0_regs_phys = virt_to_phys(&l2x0_saved_regs);
+ clean_dcache_area(&l2x0_regs_phys, sizeof(unsigned long));
+ }
return 0;
}
early_initcall(exynos4_l2x0_cache_init);
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 57/62] ARM: exynos: fix l2x0 saved regs handling
2014-03-19 19:29 ` [PATCH 57/62] ARM: exynos: fix l2x0 saved regs handling Arnd Bergmann
@ 2014-03-20 4:19 ` Kukjin Kim
0 siblings, 0 replies; 205+ messages in thread
From: Kukjin Kim @ 2014-03-20 4:19 UTC (permalink / raw)
To: linux-arm-kernel
Arnd Bergmann wrote:
>
> The exynos4_l2x0_cache_init function tries to flush the data cache
> for the location of the saved l2x0 registers and pass the physical
> address to the s5p-sleep implementation.
>
> However, the s5p-sleep code is optional, and if it is disabled,
> we get a linker error here when the l2x0_regs_phys variable does
> not exist.
>
> To solve this, use a compile-time conditional to drop this code
> if we don't want it.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Kukjin Kim <kgene.kim@samsung.com>
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Thanks,
Kukjin
> Cc: Ben Dooks <ben-linux@fluff.org>
> ---
> arch/arm/mach-exynos/common.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
> index 025fd82..b2f9bb0 100644
> --- a/arch/arm/mach-exynos/common.c
> +++ b/arch/arm/mach-exynos/common.c
> @@ -404,8 +404,10 @@ static int __init exynos4_l2x0_cache_init(void)
> if (ret)
> return ret;
>
> - l2x0_regs_phys = virt_to_phys(&l2x0_saved_regs);
> - clean_dcache_area(&l2x0_regs_phys, sizeof(unsigned long));
> + if (IS_ENABLED(CONFIG_S5P_SLEEP)) {
> + l2x0_regs_phys = virt_to_phys(&l2x0_saved_regs);
> + clean_dcache_area(&l2x0_regs_phys, sizeof(unsigned long));
> + }
> return 0;
> }
> early_initcall(exynos4_l2x0_cache_init);
> --
> 1.8.3.2
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 58/62] ARM: exynos: add missing include of linux/module.h
2014-03-19 19:28 ` Arnd Bergmann
` (57 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-20 4:23 ` Kukjin Kim
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
After the restructuring of the module.h and init.h headers,
we now need to include this explicitly here.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
arch/arm/mach-exynos/cpuidle.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c
index f57cb91..93d2dec 100644
--- a/arch/arm/mach-exynos/cpuidle.c
+++ b/arch/arm/mach-exynos/cpuidle.c
@@ -14,6 +14,7 @@
#include <linux/cpu_pm.h>
#include <linux/io.h>
#include <linux/export.h>
+#include <linux/module.h>
#include <linux/time.h>
#include <linux/platform_device.h>
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 58/62] ARM: exynos: add missing include of linux/module.h
2014-03-19 19:29 ` [PATCH 58/62] ARM: exynos: add missing include of linux/module.h Arnd Bergmann
@ 2014-03-20 4:23 ` Kukjin Kim
2014-03-21 15:42 ` Arnd Bergmann
0 siblings, 1 reply; 205+ messages in thread
From: Kukjin Kim @ 2014-03-20 4:23 UTC (permalink / raw)
To: linux-arm-kernel
Arnd Bergmann wrote:
>
> After the restructuring of the module.h and init.h headers,
> we now need to include this explicitly here.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Kukjin Kim <kgene.kim@samsung.com>
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Arnd,
If you want me to take this fixes for Samsung stuff into samsung tree,
please let me know.
Thanks,
Kukjin
> Cc: Ben Dooks <ben-linux@fluff.org>
> ---
> arch/arm/mach-exynos/cpuidle.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-
> exynos/cpuidle.c
> index f57cb91..93d2dec 100644
> --- a/arch/arm/mach-exynos/cpuidle.c
> +++ b/arch/arm/mach-exynos/cpuidle.c
> @@ -14,6 +14,7 @@
> #include <linux/cpu_pm.h>
> #include <linux/io.h>
> #include <linux/export.h>
> +#include <linux/module.h>
> #include <linux/time.h>
> #include <linux/platform_device.h>
>
> --
> 1.8.3.2
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 58/62] ARM: exynos: add missing include of linux/module.h
2014-03-20 4:23 ` Kukjin Kim
@ 2014-03-21 15:42 ` Arnd Bergmann
2014-03-21 23:40 ` Kukjin Kim
0 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-21 15:42 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 20 March 2014, Kukjin Kim wrote:
> Arnd Bergmann wrote:
> >
> > After the restructuring of the module.h and init.h headers,
> > we now need to include this explicitly here.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Tomasz Figa <tomasz.figa@gmail.com>
> > Cc: Kukjin Kim <kgene.kim@samsung.com>
>
> Acked-by: Kukjin Kim <kgene.kim@samsung.com>
>
> Arnd,
>
> If you want me to take this fixes for Samsung stuff into samsung tree,
> please let me know.
I think it's easier for me to keep the 62 fixes together as a series
this time.
When I find new bugs later on, it may be better for you and the
other platform maintainers to pick those up.
Arnd
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 58/62] ARM: exynos: add missing include of linux/module.h
2014-03-21 15:42 ` Arnd Bergmann
@ 2014-03-21 23:40 ` Kukjin Kim
0 siblings, 0 replies; 205+ messages in thread
From: Kukjin Kim @ 2014-03-21 23:40 UTC (permalink / raw)
To: linux-arm-kernel
Arnd Bergmann wrote:
>
> On Thursday 20 March 2014, Kukjin Kim wrote:
> > Arnd Bergmann wrote:
> > >
> > > After the restructuring of the module.h and init.h headers,
> > > we now need to include this explicitly here.
> > >
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > Cc: Tomasz Figa <tomasz.figa@gmail.com>
> > > Cc: Kukjin Kim <kgene.kim@samsung.com>
> >
> > Acked-by: Kukjin Kim <kgene.kim@samsung.com>
> >
> > Arnd,
> >
> > If you want me to take this fixes for Samsung stuff into samsung tree,
> > please let me know.
>
> I think it's easier for me to keep the 62 fixes together as a series
> this time.
>
OK.
> When I find new bugs later on, it may be better for you and the
> other platform maintainers to pick those up.
>
OK, thanks.
- Kukjin
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 59/62] ARM: shmobile: ak4642 needs i2c support
2014-03-19 19:28 ` Arnd Bergmann
@ 2014-03-19 19:29 ` Arnd Bergmann
-1 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
We cannot select SND_SOC_AK4642 if the I2C core layer
is disabled. Making the select statement conditional
ensures that we can build all configurations.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Simon Horman <horms@verge.net.au>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: linux-sh@vger.kernel.org
---
arch/arm/mach-shmobile/Kconfig | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 5249ff0..6e3904e 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -170,7 +170,7 @@ config MACH_MACKEREL
select ARCH_REQUIRE_GPIOLIB
select REGULATOR_FIXED_VOLTAGE if REGULATOR
select SMSC_PHY if SMSC911X
- select SND_SOC_AK4642 if SND_SIMPLE_CARD
+ select SND_SOC_AK4642 if SND_SIMPLE_CARD && I2C=y
select USE_OF
config MACH_ARMADILLO800EVA
@@ -179,7 +179,7 @@ config MACH_ARMADILLO800EVA
select ARCH_REQUIRE_GPIOLIB
select REGULATOR_FIXED_VOLTAGE if REGULATOR
select SMSC_PHY if SH_ETH
- select SND_SOC_WM8978 if SND_SIMPLE_CARD
+ select SND_SOC_WM8978 if SND_SIMPLE_CARD && I2C=y
select USE_OF
config MACH_ARMADILLO800EVA_REFERENCE
@@ -188,7 +188,7 @@ config MACH_ARMADILLO800EVA_REFERENCE
select ARCH_REQUIRE_GPIOLIB
select REGULATOR_FIXED_VOLTAGE if REGULATOR
select SMSC_PHY if SH_ETH
- select SND_SOC_WM8978 if SND_SIMPLE_CARD
+ select SND_SOC_WM8978 if SND_SIMPLE_CARD && I2C=y
select USE_OF
---help---
Use reference implementation of Aramdillo800 EVA board support
@@ -204,7 +204,7 @@ config MACH_BOCKW
select REGULATOR_FIXED_VOLTAGE if REGULATOR
select RENESAS_INTC_IRQPIN
select SND_SOC_AK4554 if SND_SIMPLE_CARD
- select SND_SOC_AK4642 if SND_SIMPLE_CARD
+ select SND_SOC_AK4642 if SND_SIMPLE_CARD && I2C=y
select USE_OF
config MACH_BOCKW_REFERENCE
@@ -277,7 +277,7 @@ config MACH_KZM9G
select ARCH_HAS_OPP
select ARCH_REQUIRE_GPIOLIB
select REGULATOR_FIXED_VOLTAGE if REGULATOR
- select SND_SOC_AK4642 if SND_SIMPLE_CARD
+ select SND_SOC_AK4642 if SND_SIMPLE_CARD && I2C=y
select USE_OF
config MACH_KZM9G_REFERENCE
@@ -285,7 +285,7 @@ config MACH_KZM9G_REFERENCE
depends on ARCH_SH73A0
select ARCH_REQUIRE_GPIOLIB
select REGULATOR_FIXED_VOLTAGE if REGULATOR
- select SND_SOC_AK4642 if SND_SIMPLE_CARD
+ select SND_SOC_AK4642 if SND_SIMPLE_CARD && I2C=y
select USE_OF
---help---
Use reference implementation of KZM-A9-GT board support
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread
* [PATCH 59/62] ARM: shmobile: ak4642 needs i2c support
@ 2014-03-19 19:29 ` Arnd Bergmann
0 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
We cannot select SND_SOC_AK4642 if the I2C core layer
is disabled. Making the select statement conditional
ensures that we can build all configurations.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Simon Horman <horms@verge.net.au>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: linux-sh at vger.kernel.org
---
arch/arm/mach-shmobile/Kconfig | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 5249ff0..6e3904e 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -170,7 +170,7 @@ config MACH_MACKEREL
select ARCH_REQUIRE_GPIOLIB
select REGULATOR_FIXED_VOLTAGE if REGULATOR
select SMSC_PHY if SMSC911X
- select SND_SOC_AK4642 if SND_SIMPLE_CARD
+ select SND_SOC_AK4642 if SND_SIMPLE_CARD && I2C=y
select USE_OF
config MACH_ARMADILLO800EVA
@@ -179,7 +179,7 @@ config MACH_ARMADILLO800EVA
select ARCH_REQUIRE_GPIOLIB
select REGULATOR_FIXED_VOLTAGE if REGULATOR
select SMSC_PHY if SH_ETH
- select SND_SOC_WM8978 if SND_SIMPLE_CARD
+ select SND_SOC_WM8978 if SND_SIMPLE_CARD && I2C=y
select USE_OF
config MACH_ARMADILLO800EVA_REFERENCE
@@ -188,7 +188,7 @@ config MACH_ARMADILLO800EVA_REFERENCE
select ARCH_REQUIRE_GPIOLIB
select REGULATOR_FIXED_VOLTAGE if REGULATOR
select SMSC_PHY if SH_ETH
- select SND_SOC_WM8978 if SND_SIMPLE_CARD
+ select SND_SOC_WM8978 if SND_SIMPLE_CARD && I2C=y
select USE_OF
---help---
Use reference implementation of Aramdillo800 EVA board support
@@ -204,7 +204,7 @@ config MACH_BOCKW
select REGULATOR_FIXED_VOLTAGE if REGULATOR
select RENESAS_INTC_IRQPIN
select SND_SOC_AK4554 if SND_SIMPLE_CARD
- select SND_SOC_AK4642 if SND_SIMPLE_CARD
+ select SND_SOC_AK4642 if SND_SIMPLE_CARD && I2C=y
select USE_OF
config MACH_BOCKW_REFERENCE
@@ -277,7 +277,7 @@ config MACH_KZM9G
select ARCH_HAS_OPP
select ARCH_REQUIRE_GPIOLIB
select REGULATOR_FIXED_VOLTAGE if REGULATOR
- select SND_SOC_AK4642 if SND_SIMPLE_CARD
+ select SND_SOC_AK4642 if SND_SIMPLE_CARD && I2C=y
select USE_OF
config MACH_KZM9G_REFERENCE
@@ -285,7 +285,7 @@ config MACH_KZM9G_REFERENCE
depends on ARCH_SH73A0
select ARCH_REQUIRE_GPIOLIB
select REGULATOR_FIXED_VOLTAGE if REGULATOR
- select SND_SOC_AK4642 if SND_SIMPLE_CARD
+ select SND_SOC_AK4642 if SND_SIMPLE_CARD && I2C=y
select USE_OF
---help---
Use reference implementation of KZM-A9-GT board support
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread
* Re: [PATCH 59/62] ARM: shmobile: ak4642 needs i2c support
2014-03-19 19:29 ` Arnd Bergmann
@ 2014-03-19 20:50 ` Sergei Shtylyov
-1 siblings, 0 replies; 205+ messages in thread
From: Sergei Shtylyov @ 2014-03-19 19:50 UTC (permalink / raw)
To: linux-arm-kernel
Hello.
On 03/19/2014 10:29 PM, Arnd Bergmann wrote:
> We cannot select SND_SOC_AK4642 if the I2C core layer
> is disabled. Making the select statement conditional
> ensures that we can build all configurations.
Yes, but you also touch WM8978 selects. Is it the same as AK4642 or you
just forgot to mention that?
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Simon Horman <horms@verge.net.au>
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Cc: linux-sh@vger.kernel.org
> ---
> arch/arm/mach-shmobile/Kconfig | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
> diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
> index 5249ff0..6e3904e 100644
> --- a/arch/arm/mach-shmobile/Kconfig
> +++ b/arch/arm/mach-shmobile/Kconfig
> @@ -170,7 +170,7 @@ config MACH_MACKEREL
> select ARCH_REQUIRE_GPIOLIB
> select REGULATOR_FIXED_VOLTAGE if REGULATOR
> select SMSC_PHY if SMSC911X
> - select SND_SOC_AK4642 if SND_SIMPLE_CARD
> + select SND_SOC_AK4642 if SND_SIMPLE_CARD && I2C=y
> select USE_OF
>
> config MACH_ARMADILLO800EVA
> @@ -179,7 +179,7 @@ config MACH_ARMADILLO800EVA
> select ARCH_REQUIRE_GPIOLIB
> select REGULATOR_FIXED_VOLTAGE if REGULATOR
> select SMSC_PHY if SH_ETH
> - select SND_SOC_WM8978 if SND_SIMPLE_CARD
> + select SND_SOC_WM8978 if SND_SIMPLE_CARD && I2C=y
> select USE_OF
>
> config MACH_ARMADILLO800EVA_REFERENCE
> @@ -188,7 +188,7 @@ config MACH_ARMADILLO800EVA_REFERENCE
> select ARCH_REQUIRE_GPIOLIB
> select REGULATOR_FIXED_VOLTAGE if REGULATOR
> select SMSC_PHY if SH_ETH
> - select SND_SOC_WM8978 if SND_SIMPLE_CARD
> + select SND_SOC_WM8978 if SND_SIMPLE_CARD && I2C=y
> select USE_OF
> ---help---
> Use reference implementation of Aramdillo800 EVA board support
[...]
WBR, Sergei
^ permalink raw reply [flat|nested] 205+ messages in thread* [PATCH 59/62] ARM: shmobile: ak4642 needs i2c support
@ 2014-03-19 20:50 ` Sergei Shtylyov
0 siblings, 0 replies; 205+ messages in thread
From: Sergei Shtylyov @ 2014-03-19 20:50 UTC (permalink / raw)
To: linux-arm-kernel
Hello.
On 03/19/2014 10:29 PM, Arnd Bergmann wrote:
> We cannot select SND_SOC_AK4642 if the I2C core layer
> is disabled. Making the select statement conditional
> ensures that we can build all configurations.
Yes, but you also touch WM8978 selects. Is it the same as AK4642 or you
just forgot to mention that?
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Simon Horman <horms@verge.net.au>
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Cc: linux-sh at vger.kernel.org
> ---
> arch/arm/mach-shmobile/Kconfig | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
> diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
> index 5249ff0..6e3904e 100644
> --- a/arch/arm/mach-shmobile/Kconfig
> +++ b/arch/arm/mach-shmobile/Kconfig
> @@ -170,7 +170,7 @@ config MACH_MACKEREL
> select ARCH_REQUIRE_GPIOLIB
> select REGULATOR_FIXED_VOLTAGE if REGULATOR
> select SMSC_PHY if SMSC911X
> - select SND_SOC_AK4642 if SND_SIMPLE_CARD
> + select SND_SOC_AK4642 if SND_SIMPLE_CARD && I2C=y
> select USE_OF
>
> config MACH_ARMADILLO800EVA
> @@ -179,7 +179,7 @@ config MACH_ARMADILLO800EVA
> select ARCH_REQUIRE_GPIOLIB
> select REGULATOR_FIXED_VOLTAGE if REGULATOR
> select SMSC_PHY if SH_ETH
> - select SND_SOC_WM8978 if SND_SIMPLE_CARD
> + select SND_SOC_WM8978 if SND_SIMPLE_CARD && I2C=y
> select USE_OF
>
> config MACH_ARMADILLO800EVA_REFERENCE
> @@ -188,7 +188,7 @@ config MACH_ARMADILLO800EVA_REFERENCE
> select ARCH_REQUIRE_GPIOLIB
> select REGULATOR_FIXED_VOLTAGE if REGULATOR
> select SMSC_PHY if SH_ETH
> - select SND_SOC_WM8978 if SND_SIMPLE_CARD
> + select SND_SOC_WM8978 if SND_SIMPLE_CARD && I2C=y
> select USE_OF
> ---help---
> Use reference implementation of Aramdillo800 EVA board support
[...]
WBR, Sergei
^ permalink raw reply [flat|nested] 205+ messages in thread* Re: [PATCH 59/62] ARM: shmobile: ak4642 needs i2c support
2014-03-19 20:50 ` Sergei Shtylyov
@ 2014-03-19 20:24 ` Arnd Bergmann
-1 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 20:24 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 19 March 2014, Sergei Shtylyov wrote:
> On 03/19/2014 10:29 PM, Arnd Bergmann wrote:
>
> > We cannot select SND_SOC_AK4642 if the I2C core layer
> > is disabled. Making the select statement conditional
> > ensures that we can build all configurations.
>
> Yes, but you also touch WM8978 selects. Is it the same as AK4642 or you
> just forgot to mention that?
My bad, I probably screwed up when I folded some older patches
into a common one.
Arnd
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 59/62] ARM: shmobile: ak4642 needs i2c support
@ 2014-03-19 20:24 ` Arnd Bergmann
0 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 20:24 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 19 March 2014, Sergei Shtylyov wrote:
> On 03/19/2014 10:29 PM, Arnd Bergmann wrote:
>
> > We cannot select SND_SOC_AK4642 if the I2C core layer
> > is disabled. Making the select statement conditional
> > ensures that we can build all configurations.
>
> Yes, but you also touch WM8978 selects. Is it the same as AK4642 or you
> just forgot to mention that?
My bad, I probably screwed up when I folded some older patches
into a common one.
Arnd
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 60/62] ARM: shmobile: work around CONFIG_PHYLIB=m
2014-03-19 19:28 ` Arnd Bergmann
@ 2014-03-19 19:29 ` Arnd Bergmann
-1 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
When phylib is set to be built as a module, the lager and koelsch
boards fail to build:
arch/arm/mach-shmobile/built-in.o: In function `lager_ksz8041_fixup':
:(.text+0x738): undefined reference to `mdiobus_read'
:(.text+0x73c): undefined reference to `mdiobus_write'
arch/arm/mach-shmobile/built-in.o: In function `koelsch_ksz8041_fixup':
:(.text+0x7e8): undefined reference to `mdiobus_read'
:(.text+0x7ec): undefined reference to `mdiobus_write'
To work around that problem, this changes the code to check for
IS_BUILTIN rather than IS_ENABLED, turning the error into a runtime
problem. It's now possible to build random configurations, but the
phy may be set up incorrectly in this case.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Simon Horman <horms@verge.net.au>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: linux-sh@vger.kernel.org
---
arch/arm/mach-shmobile/board-koelsch.c | 2 +-
arch/arm/mach-shmobile/board-lager.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-koelsch.c b/arch/arm/mach-shmobile/board-koelsch.c
index 5a034ff..b724f33 100644
--- a/arch/arm/mach-shmobile/board-koelsch.c
+++ b/arch/arm/mach-shmobile/board-koelsch.c
@@ -510,7 +510,7 @@ static void __init koelsch_init(void)
irq_set_irq_type(irq_pin(0), IRQ_TYPE_LEVEL_LOW);
- if (IS_ENABLED(CONFIG_PHYLIB))
+ if (IS_BUILTIN(CONFIG_PHYLIB))
phy_register_fixup_for_id("r8a7791-ether-ff:01",
koelsch_ksz8041_fixup);
}
diff --git a/arch/arm/mach-shmobile/board-lager.c b/arch/arm/mach-shmobile/board-lager.c
index f0104bf..67b1069 100644
--- a/arch/arm/mach-shmobile/board-lager.c
+++ b/arch/arm/mach-shmobile/board-lager.c
@@ -869,7 +869,7 @@ static void __init lager_init(void)
irq_set_irq_type(irq_pin(0), IRQ_TYPE_LEVEL_LOW);
- if (IS_ENABLED(CONFIG_PHYLIB))
+ if (IS_BUILTIN(CONFIG_PHYLIB))
phy_register_fixup_for_id("r8a7790-ether-ff:01",
lager_ksz8041_fixup);
}
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 60/62] ARM: shmobile: work around CONFIG_PHYLIB=m
@ 2014-03-19 19:29 ` Arnd Bergmann
0 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
When phylib is set to be built as a module, the lager and koelsch
boards fail to build:
arch/arm/mach-shmobile/built-in.o: In function `lager_ksz8041_fixup':
:(.text+0x738): undefined reference to `mdiobus_read'
:(.text+0x73c): undefined reference to `mdiobus_write'
arch/arm/mach-shmobile/built-in.o: In function `koelsch_ksz8041_fixup':
:(.text+0x7e8): undefined reference to `mdiobus_read'
:(.text+0x7ec): undefined reference to `mdiobus_write'
To work around that problem, this changes the code to check for
IS_BUILTIN rather than IS_ENABLED, turning the error into a runtime
problem. It's now possible to build random configurations, but the
phy may be set up incorrectly in this case.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Simon Horman <horms@verge.net.au>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: linux-sh at vger.kernel.org
---
arch/arm/mach-shmobile/board-koelsch.c | 2 +-
arch/arm/mach-shmobile/board-lager.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-koelsch.c b/arch/arm/mach-shmobile/board-koelsch.c
index 5a034ff..b724f33 100644
--- a/arch/arm/mach-shmobile/board-koelsch.c
+++ b/arch/arm/mach-shmobile/board-koelsch.c
@@ -510,7 +510,7 @@ static void __init koelsch_init(void)
irq_set_irq_type(irq_pin(0), IRQ_TYPE_LEVEL_LOW);
- if (IS_ENABLED(CONFIG_PHYLIB))
+ if (IS_BUILTIN(CONFIG_PHYLIB))
phy_register_fixup_for_id("r8a7791-ether-ff:01",
koelsch_ksz8041_fixup);
}
diff --git a/arch/arm/mach-shmobile/board-lager.c b/arch/arm/mach-shmobile/board-lager.c
index f0104bf..67b1069 100644
--- a/arch/arm/mach-shmobile/board-lager.c
+++ b/arch/arm/mach-shmobile/board-lager.c
@@ -869,7 +869,7 @@ static void __init lager_init(void)
irq_set_irq_type(irq_pin(0), IRQ_TYPE_LEVEL_LOW);
- if (IS_ENABLED(CONFIG_PHYLIB))
+ if (IS_BUILTIN(CONFIG_PHYLIB))
phy_register_fixup_for_id("r8a7790-ether-ff:01",
lager_ksz8041_fixup);
}
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* Re: [PATCH 60/62] ARM: shmobile: work around CONFIG_PHYLIB=m
2014-03-19 19:29 ` Arnd Bergmann
@ 2014-03-20 3:55 ` Simon Horman
-1 siblings, 0 replies; 205+ messages in thread
From: Simon Horman @ 2014-03-20 3:55 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Mar 19, 2014 at 08:29:57PM +0100, Arnd Bergmann wrote:
> When phylib is set to be built as a module, the lager and koelsch
> boards fail to build:
>
> arch/arm/mach-shmobile/built-in.o: In function `lager_ksz8041_fixup':
> :(.text+0x738): undefined reference to `mdiobus_read'
> :(.text+0x73c): undefined reference to `mdiobus_write'
> arch/arm/mach-shmobile/built-in.o: In function `koelsch_ksz8041_fixup':
> :(.text+0x7e8): undefined reference to `mdiobus_read'
> :(.text+0x7ec): undefined reference to `mdiobus_write'
>
> To work around that problem, this changes the code to check for
> IS_BUILTIN rather than IS_ENABLED, turning the error into a runtime
> problem. It's now possible to build random configurations, but the
> phy may be set up incorrectly in this case.
I wonder if Kconfig for koelsch should be tightened up somehow to
ensure that PHYLIB is either unselected or builtin.
Also, a minor nit, I would prefer changes for different boards
in different patches. But I can split the patch myself if its
not going to be changed otherwise.
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Simon Horman <horms@verge.net.au>
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Cc: linux-sh@vger.kernel.org
> ---
> arch/arm/mach-shmobile/board-koelsch.c | 2 +-
> arch/arm/mach-shmobile/board-lager.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-shmobile/board-koelsch.c b/arch/arm/mach-shmobile/board-koelsch.c
> index 5a034ff..b724f33 100644
> --- a/arch/arm/mach-shmobile/board-koelsch.c
> +++ b/arch/arm/mach-shmobile/board-koelsch.c
> @@ -510,7 +510,7 @@ static void __init koelsch_init(void)
>
> irq_set_irq_type(irq_pin(0), IRQ_TYPE_LEVEL_LOW);
>
> - if (IS_ENABLED(CONFIG_PHYLIB))
> + if (IS_BUILTIN(CONFIG_PHYLIB))
> phy_register_fixup_for_id("r8a7791-ether-ff:01",
> koelsch_ksz8041_fixup);
> }
> diff --git a/arch/arm/mach-shmobile/board-lager.c b/arch/arm/mach-shmobile/board-lager.c
> index f0104bf..67b1069 100644
> --- a/arch/arm/mach-shmobile/board-lager.c
> +++ b/arch/arm/mach-shmobile/board-lager.c
> @@ -869,7 +869,7 @@ static void __init lager_init(void)
>
> irq_set_irq_type(irq_pin(0), IRQ_TYPE_LEVEL_LOW);
>
> - if (IS_ENABLED(CONFIG_PHYLIB))
> + if (IS_BUILTIN(CONFIG_PHYLIB))
> phy_register_fixup_for_id("r8a7790-ether-ff:01",
> lager_ksz8041_fixup);
> }
> --
> 1.8.3.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 205+ messages in thread* [PATCH 60/62] ARM: shmobile: work around CONFIG_PHYLIB=m
@ 2014-03-20 3:55 ` Simon Horman
0 siblings, 0 replies; 205+ messages in thread
From: Simon Horman @ 2014-03-20 3:55 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Mar 19, 2014 at 08:29:57PM +0100, Arnd Bergmann wrote:
> When phylib is set to be built as a module, the lager and koelsch
> boards fail to build:
>
> arch/arm/mach-shmobile/built-in.o: In function `lager_ksz8041_fixup':
> :(.text+0x738): undefined reference to `mdiobus_read'
> :(.text+0x73c): undefined reference to `mdiobus_write'
> arch/arm/mach-shmobile/built-in.o: In function `koelsch_ksz8041_fixup':
> :(.text+0x7e8): undefined reference to `mdiobus_read'
> :(.text+0x7ec): undefined reference to `mdiobus_write'
>
> To work around that problem, this changes the code to check for
> IS_BUILTIN rather than IS_ENABLED, turning the error into a runtime
> problem. It's now possible to build random configurations, but the
> phy may be set up incorrectly in this case.
I wonder if Kconfig for koelsch should be tightened up somehow to
ensure that PHYLIB is either unselected or builtin.
Also, a minor nit, I would prefer changes for different boards
in different patches. But I can split the patch myself if its
not going to be changed otherwise.
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Simon Horman <horms@verge.net.au>
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Cc: linux-sh at vger.kernel.org
> ---
> arch/arm/mach-shmobile/board-koelsch.c | 2 +-
> arch/arm/mach-shmobile/board-lager.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-shmobile/board-koelsch.c b/arch/arm/mach-shmobile/board-koelsch.c
> index 5a034ff..b724f33 100644
> --- a/arch/arm/mach-shmobile/board-koelsch.c
> +++ b/arch/arm/mach-shmobile/board-koelsch.c
> @@ -510,7 +510,7 @@ static void __init koelsch_init(void)
>
> irq_set_irq_type(irq_pin(0), IRQ_TYPE_LEVEL_LOW);
>
> - if (IS_ENABLED(CONFIG_PHYLIB))
> + if (IS_BUILTIN(CONFIG_PHYLIB))
> phy_register_fixup_for_id("r8a7791-ether-ff:01",
> koelsch_ksz8041_fixup);
> }
> diff --git a/arch/arm/mach-shmobile/board-lager.c b/arch/arm/mach-shmobile/board-lager.c
> index f0104bf..67b1069 100644
> --- a/arch/arm/mach-shmobile/board-lager.c
> +++ b/arch/arm/mach-shmobile/board-lager.c
> @@ -869,7 +869,7 @@ static void __init lager_init(void)
>
> irq_set_irq_type(irq_pin(0), IRQ_TYPE_LEVEL_LOW);
>
> - if (IS_ENABLED(CONFIG_PHYLIB))
> + if (IS_BUILTIN(CONFIG_PHYLIB))
> phy_register_fixup_for_id("r8a7790-ether-ff:01",
> lager_ksz8041_fixup);
> }
> --
> 1.8.3.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 205+ messages in thread* Re: [PATCH 60/62] ARM: shmobile: work around CONFIG_PHYLIB=m
2014-03-20 3:55 ` Simon Horman
@ 2014-03-21 15:43 ` Arnd Bergmann
-1 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-21 15:43 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 20 March 2014, Simon Horman wrote:
> On Wed, Mar 19, 2014 at 08:29:57PM +0100, Arnd Bergmann wrote:
> > When phylib is set to be built as a module, the lager and koelsch
> > boards fail to build:
> >
> > arch/arm/mach-shmobile/built-in.o: In function `lager_ksz8041_fixup':
> > :(.text+0x738): undefined reference to `mdiobus_read'
> > :(.text+0x73c): undefined reference to `mdiobus_write'
> > arch/arm/mach-shmobile/built-in.o: In function `koelsch_ksz8041_fixup':
> > :(.text+0x7e8): undefined reference to `mdiobus_read'
> > :(.text+0x7ec): undefined reference to `mdiobus_write'
> >
> > To work around that problem, this changes the code to check for
> > IS_BUILTIN rather than IS_ENABLED, turning the error into a runtime
> > problem. It's now possible to build random configurations, but the
> > phy may be set up incorrectly in this case.
>
> I wonder if Kconfig for koelsch should be tightened up somehow to
> ensure that PHYLIB is either unselected or builtin.
>
> Also, a minor nit, I would prefer changes for different boards
> in different patches. But I can split the patch myself if its
> not going to be changed otherwise.
I would prefer to take the entire series directly into arm-soc
this time, if you don't mind.
Arnd
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 60/62] ARM: shmobile: work around CONFIG_PHYLIB=m
@ 2014-03-21 15:43 ` Arnd Bergmann
0 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-21 15:43 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 20 March 2014, Simon Horman wrote:
> On Wed, Mar 19, 2014 at 08:29:57PM +0100, Arnd Bergmann wrote:
> > When phylib is set to be built as a module, the lager and koelsch
> > boards fail to build:
> >
> > arch/arm/mach-shmobile/built-in.o: In function `lager_ksz8041_fixup':
> > :(.text+0x738): undefined reference to `mdiobus_read'
> > :(.text+0x73c): undefined reference to `mdiobus_write'
> > arch/arm/mach-shmobile/built-in.o: In function `koelsch_ksz8041_fixup':
> > :(.text+0x7e8): undefined reference to `mdiobus_read'
> > :(.text+0x7ec): undefined reference to `mdiobus_write'
> >
> > To work around that problem, this changes the code to check for
> > IS_BUILTIN rather than IS_ENABLED, turning the error into a runtime
> > problem. It's now possible to build random configurations, but the
> > phy may be set up incorrectly in this case.
>
> I wonder if Kconfig for koelsch should be tightened up somehow to
> ensure that PHYLIB is either unselected or builtin.
>
> Also, a minor nit, I would prefer changes for different boards
> in different patches. But I can split the patch myself if its
> not going to be changed otherwise.
I would prefer to take the entire series directly into arm-soc
this time, if you don't mind.
Arnd
^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: [PATCH 60/62] ARM: shmobile: work around CONFIG_PHYLIB=m
2014-03-21 15:43 ` Arnd Bergmann
@ 2014-03-24 1:35 ` Simon Horman
-1 siblings, 0 replies; 205+ messages in thread
From: Simon Horman @ 2014-03-24 1:35 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Mar 21, 2014 at 04:43:24PM +0100, Arnd Bergmann wrote:
> On Thursday 20 March 2014, Simon Horman wrote:
> > On Wed, Mar 19, 2014 at 08:29:57PM +0100, Arnd Bergmann wrote:
> > > When phylib is set to be built as a module, the lager and koelsch
> > > boards fail to build:
> > >
> > > arch/arm/mach-shmobile/built-in.o: In function `lager_ksz8041_fixup':
> > > :(.text+0x738): undefined reference to `mdiobus_read'
> > > :(.text+0x73c): undefined reference to `mdiobus_write'
> > > arch/arm/mach-shmobile/built-in.o: In function `koelsch_ksz8041_fixup':
> > > :(.text+0x7e8): undefined reference to `mdiobus_read'
> > > :(.text+0x7ec): undefined reference to `mdiobus_write'
> > >
> > > To work around that problem, this changes the code to check for
> > > IS_BUILTIN rather than IS_ENABLED, turning the error into a runtime
> > > problem. It's now possible to build random configurations, but the
> > > phy may be set up incorrectly in this case.
> >
> > I wonder if Kconfig for koelsch should be tightened up somehow to
> > ensure that PHYLIB is either unselected or builtin.
> >
> > Also, a minor nit, I would prefer changes for different boards
> > in different patches. But I can split the patch myself if its
> > not going to be changed otherwise.
>
> I would prefer to take the entire series directly into arm-soc
> this time, if you don't mind.
That I'm happy to go along with though I don't understand the motivation
for it. And regardless of how the patches go in I'd prefer if they were
split as I suggested above.
What I'm not so happy about is us potentially moving a problem from being a
compile time error, which is easy to observe, to a run-time behavioural
problem, which may be much less obvious to the beholder.
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 60/62] ARM: shmobile: work around CONFIG_PHYLIB=m
@ 2014-03-24 1:35 ` Simon Horman
0 siblings, 0 replies; 205+ messages in thread
From: Simon Horman @ 2014-03-24 1:35 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Mar 21, 2014 at 04:43:24PM +0100, Arnd Bergmann wrote:
> On Thursday 20 March 2014, Simon Horman wrote:
> > On Wed, Mar 19, 2014 at 08:29:57PM +0100, Arnd Bergmann wrote:
> > > When phylib is set to be built as a module, the lager and koelsch
> > > boards fail to build:
> > >
> > > arch/arm/mach-shmobile/built-in.o: In function `lager_ksz8041_fixup':
> > > :(.text+0x738): undefined reference to `mdiobus_read'
> > > :(.text+0x73c): undefined reference to `mdiobus_write'
> > > arch/arm/mach-shmobile/built-in.o: In function `koelsch_ksz8041_fixup':
> > > :(.text+0x7e8): undefined reference to `mdiobus_read'
> > > :(.text+0x7ec): undefined reference to `mdiobus_write'
> > >
> > > To work around that problem, this changes the code to check for
> > > IS_BUILTIN rather than IS_ENABLED, turning the error into a runtime
> > > problem. It's now possible to build random configurations, but the
> > > phy may be set up incorrectly in this case.
> >
> > I wonder if Kconfig for koelsch should be tightened up somehow to
> > ensure that PHYLIB is either unselected or builtin.
> >
> > Also, a minor nit, I would prefer changes for different boards
> > in different patches. But I can split the patch myself if its
> > not going to be changed otherwise.
>
> I would prefer to take the entire series directly into arm-soc
> this time, if you don't mind.
That I'm happy to go along with though I don't understand the motivation
for it. And regardless of how the patches go in I'd prefer if they were
split as I suggested above.
What I'm not so happy about is us potentially moving a problem from being a
compile time error, which is easy to observe, to a run-time behavioural
problem, which may be much less obvious to the beholder.
^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: [PATCH 60/62] ARM: shmobile: work around CONFIG_PHYLIB=m
2014-03-24 1:35 ` Simon Horman
@ 2014-03-24 12:04 ` Arnd Bergmann
-1 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-24 12:04 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 24 March 2014 10:35:56 Simon Horman wrote:
> On Fri, Mar 21, 2014 at 04:43:24PM +0100, Arnd Bergmann wrote:
> > On Thursday 20 March 2014, Simon Horman wrote:
> > > I wonder if Kconfig for koelsch should be tightened up somehow to
> > > ensure that PHYLIB is either unselected or builtin.
> > >
> > > Also, a minor nit, I would prefer changes for different boards
> > > in different patches. But I can split the patch myself if its
> > > not going to be changed otherwise.
> >
> > I would prefer to take the entire series directly into arm-soc
> > this time, if you don't mind.
>
> That I'm happy to go along with though I don't understand the motivation
> for it. And regardless of how the patches go in I'd prefer if they were
> split as I suggested above.
Sorry, I misunderstood you at first. I thought you meant you only split
them up when you apply them yourself. It's no problem for me to split
up this patch as well and then apply it here.
> What I'm not so happy about is us potentially moving a problem from being a
> compile time error, which is easy to observe, to a run-time behavioural
> problem, which may be much less obvious to the beholder.
I agree that it's not nice, but I couldn't come with a better approach,
and we are doing the same thing on other platforms as well.
The problems are:
* leaving the code as it is today prevents me from running all
'make randconfig' kernels successfully. I use this as an important
test case for verifying stuff we pull into the arm-soc tree.
At the moment, I have a 160-patch series that I want to get merged
upstream over time.
* Using 'select PHYLIB' from the platform is nasty because we want
to be able to turn off whole subsystems (BLOCK, NET, I2C, ...)
in Kconfig independent of the board selection. PHYLIB requires
the network code.
* Using 'depends on' to disable the board option if PHYLIB is
a module is counterintuitive.
* Makeing PHYLIB always built-in when NETDEVICE is would be a
bit wasteful.
I don't have any other ideas for solving this.
Arnd
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 60/62] ARM: shmobile: work around CONFIG_PHYLIB=m
@ 2014-03-24 12:04 ` Arnd Bergmann
0 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-24 12:04 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 24 March 2014 10:35:56 Simon Horman wrote:
> On Fri, Mar 21, 2014 at 04:43:24PM +0100, Arnd Bergmann wrote:
> > On Thursday 20 March 2014, Simon Horman wrote:
> > > I wonder if Kconfig for koelsch should be tightened up somehow to
> > > ensure that PHYLIB is either unselected or builtin.
> > >
> > > Also, a minor nit, I would prefer changes for different boards
> > > in different patches. But I can split the patch myself if its
> > > not going to be changed otherwise.
> >
> > I would prefer to take the entire series directly into arm-soc
> > this time, if you don't mind.
>
> That I'm happy to go along with though I don't understand the motivation
> for it. And regardless of how the patches go in I'd prefer if they were
> split as I suggested above.
Sorry, I misunderstood you at first. I thought you meant you only split
them up when you apply them yourself. It's no problem for me to split
up this patch as well and then apply it here.
> What I'm not so happy about is us potentially moving a problem from being a
> compile time error, which is easy to observe, to a run-time behavioural
> problem, which may be much less obvious to the beholder.
I agree that it's not nice, but I couldn't come with a better approach,
and we are doing the same thing on other platforms as well.
The problems are:
* leaving the code as it is today prevents me from running all
'make randconfig' kernels successfully. I use this as an important
test case for verifying stuff we pull into the arm-soc tree.
At the moment, I have a 160-patch series that I want to get merged
upstream over time.
* Using 'select PHYLIB' from the platform is nasty because we want
to be able to turn off whole subsystems (BLOCK, NET, I2C, ...)
in Kconfig independent of the board selection. PHYLIB requires
the network code.
* Using 'depends on' to disable the board option if PHYLIB is
a module is counterintuitive.
* Makeing PHYLIB always built-in when NETDEVICE is would be a
bit wasteful.
I don't have any other ideas for solving this.
Arnd
^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: [PATCH 60/62] ARM: shmobile: work around CONFIG_PHYLIB=m
2014-03-24 12:04 ` Arnd Bergmann
@ 2014-03-25 9:16 ` Uwe Kleine-König
-1 siblings, 0 replies; 205+ messages in thread
From: Uwe Kleine-König @ 2014-03-25 9:16 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Mar 24, 2014 at 01:04:57PM +0100, Arnd Bergmann wrote:
> On Monday 24 March 2014 10:35:56 Simon Horman wrote:
> > On Fri, Mar 21, 2014 at 04:43:24PM +0100, Arnd Bergmann wrote:
> > > On Thursday 20 March 2014, Simon Horman wrote:
> > > > I wonder if Kconfig for koelsch should be tightened up somehow to
> > > > ensure that PHYLIB is either unselected or builtin.
> > > >
> > > > Also, a minor nit, I would prefer changes for different boards
> > > > in different patches. But I can split the patch myself if its
> > > > not going to be changed otherwise.
> > >
> > > I would prefer to take the entire series directly into arm-soc
> > > this time, if you don't mind.
> >
> > That I'm happy to go along with though I don't understand the motivation
> > for it. And regardless of how the patches go in I'd prefer if they were
> > split as I suggested above.
>
> Sorry, I misunderstood you at first. I thought you meant you only split
> them up when you apply them yourself. It's no problem for me to split
> up this patch as well and then apply it here.
>
> > What I'm not so happy about is us potentially moving a problem from being a
> > compile time error, which is easy to observe, to a run-time behavioural
> > problem, which may be much less obvious to the beholder.
>
> I agree that it's not nice, but I couldn't come with a better approach,
> and we are doing the same thing on other platforms as well.
>
> The problems are:
>
> * leaving the code as it is today prevents me from running all
> 'make randconfig' kernels successfully. I use this as an important
> test case for verifying stuff we pull into the arm-soc tree.
> At the moment, I have a 160-patch series that I want to get merged
> upstream over time.
>
> * Using 'select PHYLIB' from the platform is nasty because we want
> to be able to turn off whole subsystems (BLOCK, NET, I2C, ...)
> in Kconfig independent of the board selection. PHYLIB requires
> the network code.
>
> * Using 'depends on' to disable the board option if PHYLIB is
> a module is counterintuitive.
>
> * Makeing PHYLIB always built-in when NETDEVICE is would be a
> bit wasteful.
maybe let the board
select PHYLIB if NETDEVICE
is a nice compromise?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 60/62] ARM: shmobile: work around CONFIG_PHYLIB=m
@ 2014-03-25 9:16 ` Uwe Kleine-König
0 siblings, 0 replies; 205+ messages in thread
From: Uwe Kleine-König @ 2014-03-25 9:16 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Mar 24, 2014 at 01:04:57PM +0100, Arnd Bergmann wrote:
> On Monday 24 March 2014 10:35:56 Simon Horman wrote:
> > On Fri, Mar 21, 2014 at 04:43:24PM +0100, Arnd Bergmann wrote:
> > > On Thursday 20 March 2014, Simon Horman wrote:
> > > > I wonder if Kconfig for koelsch should be tightened up somehow to
> > > > ensure that PHYLIB is either unselected or builtin.
> > > >
> > > > Also, a minor nit, I would prefer changes for different boards
> > > > in different patches. But I can split the patch myself if its
> > > > not going to be changed otherwise.
> > >
> > > I would prefer to take the entire series directly into arm-soc
> > > this time, if you don't mind.
> >
> > That I'm happy to go along with though I don't understand the motivation
> > for it. And regardless of how the patches go in I'd prefer if they were
> > split as I suggested above.
>
> Sorry, I misunderstood you at first. I thought you meant you only split
> them up when you apply them yourself. It's no problem for me to split
> up this patch as well and then apply it here.
>
> > What I'm not so happy about is us potentially moving a problem from being a
> > compile time error, which is easy to observe, to a run-time behavioural
> > problem, which may be much less obvious to the beholder.
>
> I agree that it's not nice, but I couldn't come with a better approach,
> and we are doing the same thing on other platforms as well.
>
> The problems are:
>
> * leaving the code as it is today prevents me from running all
> 'make randconfig' kernels successfully. I use this as an important
> test case for verifying stuff we pull into the arm-soc tree.
> At the moment, I have a 160-patch series that I want to get merged
> upstream over time.
>
> * Using 'select PHYLIB' from the platform is nasty because we want
> to be able to turn off whole subsystems (BLOCK, NET, I2C, ...)
> in Kconfig independent of the board selection. PHYLIB requires
> the network code.
>
> * Using 'depends on' to disable the board option if PHYLIB is
> a module is counterintuitive.
>
> * Makeing PHYLIB always built-in when NETDEVICE is would be a
> bit wasteful.
maybe let the board
select PHYLIB if NETDEVICE
is a nice compromise?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 61/62] ARM: sunxi: fix build for THUMB2_KERNEL
2014-03-19 19:28 ` Arnd Bergmann
` (60 preceding siblings ...)
(?)
@ 2014-03-19 19:29 ` Arnd Bergmann
2014-03-19 22:04 ` Rob Herring
-1 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
Building an SMP kernel for the sunxi platform with THUMB2 instructions
fails with this error at the moment:
headsmp.S:7: Error: Thumb encoding does not support an immediate here -- `msr cpsr_fsxc,#0xd3'
This changes the code to use a register for loading the
value instead, which works in both ARM and THUMB mode.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
---
arch/arm/mach-sunxi/headsmp.S | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-sunxi/headsmp.S b/arch/arm/mach-sunxi/headsmp.S
index a10d494..a8e0fef 100644
--- a/arch/arm/mach-sunxi/headsmp.S
+++ b/arch/arm/mach-sunxi/headsmp.S
@@ -4,6 +4,7 @@
.section ".text.head", "ax"
ENTRY(sun6i_secondary_startup)
- msr cpsr_fsxc, #0xd3
+ mov r0, #0xd3
+ msr cpsr_fsxc, r0
b secondary_startup
ENDPROC(sun6i_secondary_startup)
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 61/62] ARM: sunxi: fix build for THUMB2_KERNEL
2014-03-19 19:29 ` [PATCH 61/62] ARM: sunxi: fix build for THUMB2_KERNEL Arnd Bergmann
@ 2014-03-19 22:04 ` Rob Herring
2014-03-20 10:59 ` Arnd Bergmann
0 siblings, 1 reply; 205+ messages in thread
From: Rob Herring @ 2014-03-19 22:04 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Mar 19, 2014 at 2:29 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> Building an SMP kernel for the sunxi platform with THUMB2 instructions
> fails with this error at the moment:
>
> headsmp.S:7: Error: Thumb encoding does not support an immediate here -- `msr cpsr_fsxc,#0xd3'
>
> This changes the code to use a register for loading the
> value instead, which works in both ARM and THUMB mode.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> arch/arm/mach-sunxi/headsmp.S | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-sunxi/headsmp.S b/arch/arm/mach-sunxi/headsmp.S
> index a10d494..a8e0fef 100644
> --- a/arch/arm/mach-sunxi/headsmp.S
> +++ b/arch/arm/mach-sunxi/headsmp.S
> @@ -4,6 +4,7 @@
> .section ".text.head", "ax"
>
> ENTRY(sun6i_secondary_startup)
> - msr cpsr_fsxc, #0xd3
> + mov r0, #0xd3
> + msr cpsr_fsxc, r0
> b secondary_startup
Secondary cores should always enter the kernel in ARM mode like the
primary core, right? So we need the same switching to Thumb2 as
head.S, but even secondary_startup doesn't do any switching. So either
platforms jump into the kernel with a bx and happen to work or
secondary boot is broken for Thumb2 kernels.
Also, secondary_startup takes care of making sure the core is in SVC
mode, so this function shouldn't be needed in the first place.
Rob
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 61/62] ARM: sunxi: fix build for THUMB2_KERNEL
2014-03-19 22:04 ` Rob Herring
@ 2014-03-20 10:59 ` Arnd Bergmann
2014-03-21 15:54 ` Rob Herring
0 siblings, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-20 10:59 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 19 March 2014, Rob Herring wrote:
> > --- a/arch/arm/mach-sunxi/headsmp.S
> > +++ b/arch/arm/mach-sunxi/headsmp.S
> > @@ -4,6 +4,7 @@
> > .section ".text.head", "ax"
> >
> > ENTRY(sun6i_secondary_startup)
> > - msr cpsr_fsxc, #0xd3
> > + mov r0, #0xd3
> > + msr cpsr_fsxc, r0
> > b secondary_startup
>
> Secondary cores should always enter the kernel in ARM mode like the
> primary core, right? So we need the same switching to Thumb2 as
> head.S, but even secondary_startup doesn't do any switching. So either
> platforms jump into the kernel with a bx and happen to work or
> secondary boot is broken for Thumb2 kernels.
Makes sense. So should we instead do this?
.arm
ENTRY(sun6i_secondary_startup)
ARM_BE8(setend be ) /* I suppose we need this too */
msr cpsr_fsxc, #0xd3
ldr r0, =secondary_startup
bx r0
(I'm a bit confused about when to use what branch instruction, so
forgive me if the above doesn't make sense)
> Also, secondary_startup takes care of making sure the core is in SVC
> mode, so this function shouldn't be needed in the first place.
I'd rather not change this part, unless Maxime can confirm that it's
not necessary. I would assume that it's there for a reason otherwise.
Arnd
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 61/62] ARM: sunxi: fix build for THUMB2_KERNEL
2014-03-20 10:59 ` Arnd Bergmann
@ 2014-03-21 15:54 ` Rob Herring
2014-03-21 16:05 ` Arnd Bergmann
2014-03-21 19:11 ` Maxime Ripard
0 siblings, 2 replies; 205+ messages in thread
From: Rob Herring @ 2014-03-21 15:54 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Mar 20, 2014 at 5:59 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 19 March 2014, Rob Herring wrote:
>
>> > --- a/arch/arm/mach-sunxi/headsmp.S
>> > +++ b/arch/arm/mach-sunxi/headsmp.S
>> > @@ -4,6 +4,7 @@
>> > .section ".text.head", "ax"
>> >
>> > ENTRY(sun6i_secondary_startup)
>> > - msr cpsr_fsxc, #0xd3
>> > + mov r0, #0xd3
>> > + msr cpsr_fsxc, r0
>> > b secondary_startup
>>
>> Secondary cores should always enter the kernel in ARM mode like the
>> primary core, right? So we need the same switching to Thumb2 as
>> head.S, but even secondary_startup doesn't do any switching. So either
>> platforms jump into the kernel with a bx and happen to work or
>> secondary boot is broken for Thumb2 kernels.
>
> Makes sense. So should we instead do this?
That would work, but I'm more worried that Thumb2 may be broken on
other platforms.
>
> .arm
> ENTRY(sun6i_secondary_startup)
> ARM_BE8(setend be ) /* I suppose we need this too */
> msr cpsr_fsxc, #0xd3
> ldr r0, =secondary_startup
> bx r0
>
> (I'm a bit confused about when to use what branch instruction, so
> forgive me if the above doesn't make sense)
>
>> Also, secondary_startup takes care of making sure the core is in SVC
>> mode, so this function shouldn't be needed in the first place.
>
> I'd rather not change this part, unless Maxime can confirm that it's
> not necessary. I would assume that it's there for a reason otherwise.
That often proves to not be the case. :) Initial SOC code is whatever
we've failed to delete from vendor BSP code.
Looking at the review comments adding SMP boot, there was discussion
about entering in HYP mode and that being dependent on u-boot support,
but nothing whether this was needed or not. So it appears to me we
probably enter the kernel in the reset default of secure supervisor
mode and this code is a nop. This code would not work if it was HYP
mode. So when u-boot does correctly setup HYP mode, this code will be
broken (although other parts of smp_ops will be too).
The first things secondary_startup do are:
-set BE mode
-if in HYP mode, install hyp vectors and drop to SVC
-set the CPSR to a know value (safe_svcmode_maskall r9)
So this code is completely redundant and unnecessary. If there were
some reason for it, then it should be in secondary_startup.
Rob
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 61/62] ARM: sunxi: fix build for THUMB2_KERNEL
2014-03-21 15:54 ` Rob Herring
@ 2014-03-21 16:05 ` Arnd Bergmann
2014-03-21 16:24 ` Arnd Bergmann
2014-03-21 19:11 ` Maxime Ripard
1 sibling, 1 reply; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-21 16:05 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 21 March 2014 10:54:49 Rob Herring wrote:
> On Thu, Mar 20, 2014 at 5:59 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Wednesday 19 March 2014, Rob Herring wrote:
> >
> >> > --- a/arch/arm/mach-sunxi/headsmp.S
> >> > +++ b/arch/arm/mach-sunxi/headsmp.S
> >> > @@ -4,6 +4,7 @@
> >> > .section ".text.head", "ax"
> >> >
> >> > ENTRY(sun6i_secondary_startup)
> >> > - msr cpsr_fsxc, #0xd3
> >> > + mov r0, #0xd3
> >> > + msr cpsr_fsxc, r0
> >> > b secondary_startup
> >>
> >> Secondary cores should always enter the kernel in ARM mode like the
> >> primary core, right? So we need the same switching to Thumb2 as
> >> head.S, but even secondary_startup doesn't do any switching. So either
> >> platforms jump into the kernel with a bx and happen to work or
> >> secondary boot is broken for Thumb2 kernels.
> >
> > Makes sense. So should we instead do this?
>
> That would work, but I'm more worried that Thumb2 may be broken on
> other platforms.
I'm rather sure it is. I have found lots of build-time bugs with
thumb2, so by extrapolation there are more run-time bugs. I have
considered just enabling it in multi_v7_defconfig though, mainly
to see what would break ;-).
> > .arm
> > ENTRY(sun6i_secondary_startup)
> > ARM_BE8(setend be ) /* I suppose we need this too */
> > msr cpsr_fsxc, #0xd3
> > ldr r0, =secondary_startup
> > bx r0
> >
> > (I'm a bit confused about when to use what branch instruction, so
> > forgive me if the above doesn't make sense)
> >
> >> Also, secondary_startup takes care of making sure the core is in SVC
> >> mode, so this function shouldn't be needed in the first place.
> >
> > I'd rather not change this part, unless Maxime can confirm that it's
> > not necessary. I would assume that it's there for a reason otherwise.
>
> That often proves to not be the case. :) Initial SOC code is whatever
> we've failed to delete from vendor BSP code.
>
> Looking at the review comments adding SMP boot, there was discussion
> about entering in HYP mode and that being dependent on u-boot support,
> but nothing whether this was needed or not. So it appears to me we
> probably enter the kernel in the reset default of secure supervisor
> mode and this code is a nop. This code would not work if it was HYP
> mode. So when u-boot does correctly setup HYP mode, this code will be
> broken (although other parts of smp_ops will be too).
>
> The first things secondary_startup do are:
>
> -set BE mode
> -if in HYP mode, install hyp vectors and drop to SVC
> -set the CPSR to a know value (safe_svcmode_maskall r9)
>
> So this code is completely redundant and unnecessary. If there were
> some reason for it, then it should be in secondary_startup.
Ah, thanks for the clarification. Shall we just delete the file then
and jump straight to secondary_startup?
Arnd
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 61/62] ARM: sunxi: fix build for THUMB2_KERNEL
2014-03-21 16:05 ` Arnd Bergmann
@ 2014-03-21 16:24 ` Arnd Bergmann
2014-03-21 18:21 ` Rob Herring
2014-03-24 13:47 ` Maxime Ripard
0 siblings, 2 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-21 16:24 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 21 March 2014 17:05:09 Arnd Bergmann wrote:
> On Friday 21 March 2014 10:54:49 Rob Herring wrote:
> > The first things secondary_startup do are:
> >
> > -set BE mode
> > -if in HYP mode, install hyp vectors and drop to SVC
> > -set the CPSR to a know value (safe_svcmode_maskall r9)
> >
> > So this code is completely redundant and unnecessary. If there were
> > some reason for it, then it should be in secondary_startup.
>
> Ah, thanks for the clarification. Shall we just delete the file then
> and jump straight to secondary_startup?
Maxime, can you test the new version?
>From 2f6220cee15e45446c43e5c43affa85a6c407b31 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Sun, 16 Mar 2014 18:04:54 +0100
Subject: [PATCH] ARM: sunxi: fix build for THUMB2_KERNEL
Building an SMP kernel for the sunxi platform with THUMB2 instructions
fails with this error at the moment:
headsmp.S:7: Error: Thumb encoding does not support an immediate here -- `msr cpsr_fsxc,#0xd3'
Since the generic secondary_startup function already does
the same thing in a safe way, we can just drop the private
sunxi implementation and jump straight to secondary_startup.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
diff --git a/arch/arm/mach-sunxi/Makefile b/arch/arm/mach-sunxi/Makefile
index d939720..27b168f 100644
--- a/arch/arm/mach-sunxi/Makefile
+++ b/arch/arm/mach-sunxi/Makefile
@@ -1,2 +1,2 @@
obj-$(CONFIG_ARCH_SUNXI) += sunxi.o
-obj-$(CONFIG_SMP) += platsmp.o headsmp.o
+obj-$(CONFIG_SMP) += platsmp.o
diff --git a/arch/arm/mach-sunxi/common.h b/arch/arm/mach-sunxi/common.h
index 9e5ac47..08deb30 100644
--- a/arch/arm/mach-sunxi/common.h
+++ b/arch/arm/mach-sunxi/common.h
@@ -13,7 +13,6 @@
#ifndef __ARCH_SUNXI_COMMON_H_
#define __ARCH_SUNXI_COMMON_H_
-void sun6i_secondary_startup(void);
extern struct smp_operations sun6i_smp_ops;
#endif /* __ARCH_SUNXI_COMMON_H_ */
diff --git a/arch/arm/mach-sunxi/headsmp.S b/arch/arm/mach-sunxi/headsmp.S
deleted file mode 100644
index a10d494..0000000
--- a/arch/arm/mach-sunxi/headsmp.S
+++ /dev/null
@@ -1,9 +0,0 @@
-#include <linux/linkage.h>
-#include <linux/init.h>
-
- .section ".text.head", "ax"
-
-ENTRY(sun6i_secondary_startup)
- msr cpsr_fsxc, #0xd3
- b secondary_startup
-ENDPROC(sun6i_secondary_startup)
diff --git a/arch/arm/mach-sunxi/platsmp.c b/arch/arm/mach-sunxi/platsmp.c
index 7b141d8..3f9b889 100644
--- a/arch/arm/mach-sunxi/platsmp.c
+++ b/arch/arm/mach-sunxi/platsmp.c
@@ -82,7 +82,7 @@ static int sun6i_smp_boot_secondary(unsigned int cpu,
spin_lock(&cpu_lock);
/* Set CPU boot address */
- writel(virt_to_phys(sun6i_secondary_startup),
+ writel(virt_to_phys(secondary_startup),
cpucfg_membase + CPUCFG_PRIVATE0_REG);
/* Assert the CPU core in reset */
@@ -120,5 +120,5 @@ static int sun6i_smp_boot_secondary(unsigned int cpu,
struct smp_operations sun6i_smp_ops __initdata = {
.smp_prepare_cpus = sun6i_smp_prepare_cpus,
- .smp_boot_secondary = sun6i_smp_boot_secondary,
+ .smp_boot_secondary = sun6i_smp_secondary_startup,
};
^ permalink raw reply related [flat|nested] 205+ messages in thread* [PATCH 61/62] ARM: sunxi: fix build for THUMB2_KERNEL
2014-03-21 16:24 ` Arnd Bergmann
@ 2014-03-21 18:21 ` Rob Herring
2014-03-21 18:40 ` Arnd Bergmann
2014-03-24 13:47 ` Maxime Ripard
1 sibling, 1 reply; 205+ messages in thread
From: Rob Herring @ 2014-03-21 18:21 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Mar 21, 2014 at 11:24 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 21 March 2014 17:05:09 Arnd Bergmann wrote:
>> On Friday 21 March 2014 10:54:49 Rob Herring wrote:
>> > The first things secondary_startup do are:
>> >
>> > -set BE mode
>> > -if in HYP mode, install hyp vectors and drop to SVC
>> > -set the CPSR to a know value (safe_svcmode_maskall r9)
>> >
>> > So this code is completely redundant and unnecessary. If there were
>> > some reason for it, then it should be in secondary_startup.
>>
>> Ah, thanks for the clarification. Shall we just delete the file then
>> and jump straight to secondary_startup?
>
> Maxime, can you test the new version?
>
> From 2f6220cee15e45446c43e5c43affa85a6c407b31 Mon Sep 17 00:00:00 2001
> From: Arnd Bergmann <arnd@arndb.de>
> Date: Sun, 16 Mar 2014 18:04:54 +0100
> Subject: [PATCH] ARM: sunxi: fix build for THUMB2_KERNEL
>
> Building an SMP kernel for the sunxi platform with THUMB2 instructions
> fails with this error at the moment:
>
> headsmp.S:7: Error: Thumb encoding does not support an immediate here -- `msr cpsr_fsxc,#0xd3'
>
> Since the generic secondary_startup function already does
> the same thing in a safe way, we can just drop the private
> sunxi implementation and jump straight to secondary_startup.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
One issue below, but otherwise:
Acked-by: Rob Herring <robh@kernel.org>
> diff --git a/arch/arm/mach-sunxi/Makefile b/arch/arm/mach-sunxi/Makefile
> index d939720..27b168f 100644
> --- a/arch/arm/mach-sunxi/Makefile
> +++ b/arch/arm/mach-sunxi/Makefile
> @@ -1,2 +1,2 @@
> obj-$(CONFIG_ARCH_SUNXI) += sunxi.o
> -obj-$(CONFIG_SMP) += platsmp.o headsmp.o
> +obj-$(CONFIG_SMP) += platsmp.o
> diff --git a/arch/arm/mach-sunxi/common.h b/arch/arm/mach-sunxi/common.h
> index 9e5ac47..08deb30 100644
> --- a/arch/arm/mach-sunxi/common.h
> +++ b/arch/arm/mach-sunxi/common.h
> @@ -13,7 +13,6 @@
> #ifndef __ARCH_SUNXI_COMMON_H_
> #define __ARCH_SUNXI_COMMON_H_
>
> -void sun6i_secondary_startup(void);
> extern struct smp_operations sun6i_smp_ops;
>
> #endif /* __ARCH_SUNXI_COMMON_H_ */
> diff --git a/arch/arm/mach-sunxi/headsmp.S b/arch/arm/mach-sunxi/headsmp.S
> deleted file mode 100644
> index a10d494..0000000
> --- a/arch/arm/mach-sunxi/headsmp.S
> +++ /dev/null
> @@ -1,9 +0,0 @@
> -#include <linux/linkage.h>
> -#include <linux/init.h>
> -
> - .section ".text.head", "ax"
> -
> -ENTRY(sun6i_secondary_startup)
> - msr cpsr_fsxc, #0xd3
> - b secondary_startup
> -ENDPROC(sun6i_secondary_startup)
> diff --git a/arch/arm/mach-sunxi/platsmp.c b/arch/arm/mach-sunxi/platsmp.c
> index 7b141d8..3f9b889 100644
> --- a/arch/arm/mach-sunxi/platsmp.c
> +++ b/arch/arm/mach-sunxi/platsmp.c
> @@ -82,7 +82,7 @@ static int sun6i_smp_boot_secondary(unsigned int cpu,
> spin_lock(&cpu_lock);
>
> /* Set CPU boot address */
> - writel(virt_to_phys(sun6i_secondary_startup),
> + writel(virt_to_phys(secondary_startup),
> cpucfg_membase + CPUCFG_PRIVATE0_REG);
>
> /* Assert the CPU core in reset */
> @@ -120,5 +120,5 @@ static int sun6i_smp_boot_secondary(unsigned int cpu,
>
> struct smp_operations sun6i_smp_ops __initdata = {
> .smp_prepare_cpus = sun6i_smp_prepare_cpus,
> - .smp_boot_secondary = sun6i_smp_boot_secondary,
> + .smp_boot_secondary = sun6i_smp_secondary_startup,
?? This looks unintentional.
Rob
^ permalink raw reply [flat|nested] 205+ messages in thread* [PATCH 61/62] ARM: sunxi: fix build for THUMB2_KERNEL
2014-03-21 18:21 ` Rob Herring
@ 2014-03-21 18:40 ` Arnd Bergmann
0 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-21 18:40 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 21 March 2014 13:21:04 Rob Herring wrote:
> > diff --git a/arch/arm/mach-sunxi/platsmp.c b/arch/arm/mach-sunxi/platsmp.c
> > index 7b141d8..3f9b889 100644
> > --- a/arch/arm/mach-sunxi/platsmp.c
> > +++ b/arch/arm/mach-sunxi/platsmp.c
> > @@ -82,7 +82,7 @@ static int sun6i_smp_boot_secondary(unsigned int cpu,
> > spin_lock(&cpu_lock);
> >
> > /* Set CPU boot address */
> > - writel(virt_to_phys(sun6i_secondary_startup),
> > + writel(virt_to_phys(secondary_startup),
> > cpucfg_membase + CPUCFG_PRIVATE0_REG);
> >
> > /* Assert the CPU core in reset */
> > @@ -120,5 +120,5 @@ static int sun6i_smp_boot_secondary(unsigned int cpu,
> >
> > struct smp_operations sun6i_smp_ops __initdata = {
> > .smp_prepare_cpus = sun6i_smp_prepare_cpus,
> > - .smp_boot_secondary = sun6i_smp_boot_secondary,
> > + .smp_boot_secondary = sun6i_smp_secondary_startup,
>
> ?? This looks unintentional.
>
Yes, I just noticed the same thing after testing the resulting tree.
I also had to add a global declaration for secondary_startup, which apparently
mach-qcom also needs but added locally.
Arnd
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 61/62] ARM: sunxi: fix build for THUMB2_KERNEL
2014-03-21 16:24 ` Arnd Bergmann
2014-03-21 18:21 ` Rob Herring
@ 2014-03-24 13:47 ` Maxime Ripard
1 sibling, 0 replies; 205+ messages in thread
From: Maxime Ripard @ 2014-03-24 13:47 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Mar 21, 2014 at 05:24:21PM +0100, Arnd Bergmann wrote:
> On Friday 21 March 2014 17:05:09 Arnd Bergmann wrote:
> > On Friday 21 March 2014 10:54:49 Rob Herring wrote:
> > > The first things secondary_startup do are:
> > >
> > > -set BE mode
> > > -if in HYP mode, install hyp vectors and drop to SVC
> > > -set the CPSR to a know value (safe_svcmode_maskall r9)
> > >
> > > So this code is completely redundant and unnecessary. If there were
> > > some reason for it, then it should be in secondary_startup.
> >
> > Ah, thanks for the clarification. Shall we just delete the file then
> > and jump straight to secondary_startup?
>
> Maxime, can you test the new version?
>
> From 2f6220cee15e45446c43e5c43affa85a6c407b31 Mon Sep 17 00:00:00 2001
> From: Arnd Bergmann <arnd@arndb.de>
> Date: Sun, 16 Mar 2014 18:04:54 +0100
> Subject: [PATCH] ARM: sunxi: fix build for THUMB2_KERNEL
>
> Building an SMP kernel for the sunxi platform with THUMB2 instructions
> fails with this error at the moment:
>
> headsmp.S:7: Error: Thumb encoding does not support an immediate here -- `msr cpsr_fsxc,#0xd3'
>
> Since the generic secondary_startup function already does
> the same thing in a safe way, we can just drop the private
> sunxi implementation and jump straight to secondary_startup.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
With the additional changes you mentionned later that unbreaks the
compilation, you have my acked-by.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140324/92693cd9/attachment-0001.sig>
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 61/62] ARM: sunxi: fix build for THUMB2_KERNEL
2014-03-21 15:54 ` Rob Herring
2014-03-21 16:05 ` Arnd Bergmann
@ 2014-03-21 19:11 ` Maxime Ripard
1 sibling, 0 replies; 205+ messages in thread
From: Maxime Ripard @ 2014-03-21 19:11 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Mar 21, 2014 at 10:54:49AM -0500, Rob Herring wrote:
> >
> > .arm
> > ENTRY(sun6i_secondary_startup)
> > ARM_BE8(setend be ) /* I suppose we need this too */
> > msr cpsr_fsxc, #0xd3
> > ldr r0, =secondary_startup
> > bx r0
> >
> > (I'm a bit confused about when to use what branch instruction, so
> > forgive me if the above doesn't make sense)
> >
> >> Also, secondary_startup takes care of making sure the core is in SVC
> >> mode, so this function shouldn't be needed in the first place.
> >
> > I'd rather not change this part, unless Maxime can confirm that it's
> > not necessary. I would assume that it's there for a reason otherwise.
>
> That often proves to not be the case. :) Initial SOC code is whatever
> we've failed to delete from vendor BSP code.
Yep, it definitely looks like it.
> Looking at the review comments adding SMP boot, there was discussion
> about entering in HYP mode and that being dependent on u-boot support,
> but nothing whether this was needed or not. So it appears to me we
> probably enter the kernel in the reset default of secure supervisor
> mode and this code is a nop. This code would not work if it was HYP
> mode. So when u-boot does correctly setup HYP mode, this code will be
> broken (although other parts of smp_ops will be too).
Actually, we don't have any proper bootloader support for this SoC,
and we're stuck with Allwinner's bootloader.
Bootloader support will come eventually, but I wouldn't worry too much
about HYP for now. And whenever we will have such a bootloader, we
will use PSCI, so we won't need to worry about it either.
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140321/9abe1377/attachment-0001.sig>
^ permalink raw reply [flat|nested] 205+ messages in thread
[parent not found: <1395257399-359545-1-git-send-email-arnd-r2nGTMty4D4@public.gmane.org>]
* [PATCH 62/62] ARM: tegra: make debug_ll code build for ARMv6
2014-03-19 19:28 ` Arnd Bergmann
@ 2014-03-19 19:29 ` Arnd Bergmann
-1 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: arm-DgEjT+Ai2ygdnm+yROfE0A
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Arnd Bergmann,
Stephen Warren, Thierry Reding,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In a combined ARMv6/v7 kernel, we cannot use the
movt/movw instructions to load an immediate, as they
are not valid on ARMv6.
This changes the file to use an indirect load instead,
as lots of other implementations do.
Signed-off-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Cc: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
Cc: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
---
arch/arm/include/debug/tegra.S | 18 ++++++++----------
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/arch/arm/include/debug/tegra.S b/arch/arm/include/debug/tegra.S
index f98763f..3bc8059 100644
--- a/arch/arm/include/debug/tegra.S
+++ b/arch/arm/include/debug/tegra.S
@@ -53,8 +53,7 @@
#define checkuart(rp, rv, lhu, bit, uart) \
/* Load address of CLK_RST register */ \
- movw rp, #TEGRA_CLK_RST_DEVICES_##lhu & 0xffff ; \
- movt rp, #TEGRA_CLK_RST_DEVICES_##lhu >> 16 ; \
+ ldr rp, =TEGRA_CLK_RST_DEVICES_##lhu ; \
/* Load value from CLK_RST register */ \
ldr rp, [rp, #0] ; \
/* Test UART's reset bit */ \
@@ -62,8 +61,7 @@
/* If set, can't use UART; jump to save no UART */ \
bne 90f ; \
/* Load address of CLK_OUT_ENB register */ \
- movw rp, #TEGRA_CLK_OUT_ENB_##lhu & 0xffff ; \
- movt rp, #TEGRA_CLK_OUT_ENB_##lhu >> 16 ; \
+ ldr rp, =TEGRA_CLK_OUT_ENB_##lhu ; \
/* Load value from CLK_OUT_ENB register */ \
ldr rp, [rp, #0] ; \
/* Test UART's clock enable bit */ \
@@ -71,8 +69,7 @@
/* If clear, can't use UART; jump to save no UART */ \
beq 90f ; \
/* Passed all tests, load address of UART registers */ \
- movw rp, #TEGRA_UART##uart##_BASE & 0xffff ; \
- movt rp, #TEGRA_UART##uart##_BASE >> 16 ; \
+ ldr rp, =TEGRA_UART##uart##_BASE ; \
/* Jump to save UART address */ \
b 91f
@@ -90,15 +87,16 @@
#ifdef CONFIG_TEGRA_DEBUG_UART_AUTO_ODMDATA
/* Check ODMDATA */
-10: movw \rp, #TEGRA_PMC_SCRATCH20 & 0xffff
- movt \rp, #TEGRA_PMC_SCRATCH20 >> 16
+10: ldr \rp, =TEGRA_PMC_SCRATCH20
ldr \rp, [\rp, #0] @ Load PMC_SCRATCH20
- ubfx \rv, \rp, #18, #2 @ 19:18 are console type
+ lsr \rv, \rp, #18 @ 19:18 are console type
+ and \rv, \rv, #3
cmp \rv, #2 @ 2 and 3 mean DCC, UART
beq 11f @ some boards swap the meaning
cmp \rv, #3 @ so accept either
bne 90f
-11: ubfx \rv, \rp, #15, #3 @ 17:15 are UART ID
+11: lsr \rv, \rp, #15 @ 17:15 are UART ID
+ and \rv, #7
cmp \rv, #0 @ UART 0?
beq 20f
cmp \rv, #1 @ UART 1?
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread
* [PATCH 62/62] ARM: tegra: make debug_ll code build for ARMv6
@ 2014-03-19 19:29 ` Arnd Bergmann
0 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
In a combined ARMv6/v7 kernel, we cannot use the
movt/movw instructions to load an immediate, as they
are not valid on ARMv6.
This changes the file to use an indirect load instead,
as lots of other implementations do.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: linux-tegra at vger.kernel.org
---
arch/arm/include/debug/tegra.S | 18 ++++++++----------
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/arch/arm/include/debug/tegra.S b/arch/arm/include/debug/tegra.S
index f98763f..3bc8059 100644
--- a/arch/arm/include/debug/tegra.S
+++ b/arch/arm/include/debug/tegra.S
@@ -53,8 +53,7 @@
#define checkuart(rp, rv, lhu, bit, uart) \
/* Load address of CLK_RST register */ \
- movw rp, #TEGRA_CLK_RST_DEVICES_##lhu & 0xffff ; \
- movt rp, #TEGRA_CLK_RST_DEVICES_##lhu >> 16 ; \
+ ldr rp, =TEGRA_CLK_RST_DEVICES_##lhu ; \
/* Load value from CLK_RST register */ \
ldr rp, [rp, #0] ; \
/* Test UART's reset bit */ \
@@ -62,8 +61,7 @@
/* If set, can't use UART; jump to save no UART */ \
bne 90f ; \
/* Load address of CLK_OUT_ENB register */ \
- movw rp, #TEGRA_CLK_OUT_ENB_##lhu & 0xffff ; \
- movt rp, #TEGRA_CLK_OUT_ENB_##lhu >> 16 ; \
+ ldr rp, =TEGRA_CLK_OUT_ENB_##lhu ; \
/* Load value from CLK_OUT_ENB register */ \
ldr rp, [rp, #0] ; \
/* Test UART's clock enable bit */ \
@@ -71,8 +69,7 @@
/* If clear, can't use UART; jump to save no UART */ \
beq 90f ; \
/* Passed all tests, load address of UART registers */ \
- movw rp, #TEGRA_UART##uart##_BASE & 0xffff ; \
- movt rp, #TEGRA_UART##uart##_BASE >> 16 ; \
+ ldr rp, =TEGRA_UART##uart##_BASE ; \
/* Jump to save UART address */ \
b 91f
@@ -90,15 +87,16 @@
#ifdef CONFIG_TEGRA_DEBUG_UART_AUTO_ODMDATA
/* Check ODMDATA */
-10: movw \rp, #TEGRA_PMC_SCRATCH20 & 0xffff
- movt \rp, #TEGRA_PMC_SCRATCH20 >> 16
+10: ldr \rp, =TEGRA_PMC_SCRATCH20
ldr \rp, [\rp, #0] @ Load PMC_SCRATCH20
- ubfx \rv, \rp, #18, #2 @ 19:18 are console type
+ lsr \rv, \rp, #18 @ 19:18 are console type
+ and \rv, \rv, #3
cmp \rv, #2 @ 2 and 3 mean DCC, UART
beq 11f @ some boards swap the meaning
cmp \rv, #3 @ so accept either
bne 90f
-11: ubfx \rv, \rp, #15, #3 @ 17:15 are UART ID
+11: lsr \rv, \rp, #15 @ 17:15 are UART ID
+ and \rv, #7
cmp \rv, #0 @ UART 0?
beq 20f
cmp \rv, #1 @ UART 1?
--
1.8.3.2
^ permalink raw reply related [flat|nested] 205+ messages in thread
[parent not found: <1395257399-359545-63-git-send-email-arnd-r2nGTMty4D4@public.gmane.org>]
* Re: [PATCH 62/62] ARM: tegra: make debug_ll code build for ARMv6
2014-03-19 19:29 ` Arnd Bergmann
@ 2014-03-19 19:40 ` Stephen Warren
-1 siblings, 0 replies; 205+ messages in thread
From: Stephen Warren @ 2014-03-19 19:40 UTC (permalink / raw)
To: Arnd Bergmann, arm-DgEjT+Ai2ygdnm+yROfE0A
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thierry Reding, linux-tegra-u79uwXL29TY76Z2rM5mHXA
On 03/19/2014 01:29 PM, Arnd Bergmann wrote:
> In a combined ARMv6/v7 kernel, we cannot use the
> movt/movw instructions to load an immediate, as they
> are not valid on ARMv6.
>
> This changes the file to use an indirect load instead,
> as lots of other implementations do.
Hmmm. This code is guaranteed to only execute on Tegra (well, perhaps
someone can turn on the wrong debug option and run it on non-Tegra, but
then it's guaranteed not to work since the HW it touches doesn't exist).
As such, the code ought to be able to use ARMv7 instructions.
As a fix for similar issues in assembly code in arch/arm/mach-tegra/*.S,
Makefile there does:
asflags-y += -march=armv7-a
(I think you added that? Yes, in 408e713545ca "ARM: tegra: build
assembly files with -march=armv7-a")
Shouldn't we use the same fix in this case too?
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 62/62] ARM: tegra: make debug_ll code build for ARMv6
@ 2014-03-19 19:40 ` Stephen Warren
0 siblings, 0 replies; 205+ messages in thread
From: Stephen Warren @ 2014-03-19 19:40 UTC (permalink / raw)
To: linux-arm-kernel
On 03/19/2014 01:29 PM, Arnd Bergmann wrote:
> In a combined ARMv6/v7 kernel, we cannot use the
> movt/movw instructions to load an immediate, as they
> are not valid on ARMv6.
>
> This changes the file to use an indirect load instead,
> as lots of other implementations do.
Hmmm. This code is guaranteed to only execute on Tegra (well, perhaps
someone can turn on the wrong debug option and run it on non-Tegra, but
then it's guaranteed not to work since the HW it touches doesn't exist).
As such, the code ought to be able to use ARMv7 instructions.
As a fix for similar issues in assembly code in arch/arm/mach-tegra/*.S,
Makefile there does:
asflags-y += -march=armv7-a
(I think you added that? Yes, in 408e713545ca "ARM: tegra: build
assembly files with -march=armv7-a")
Shouldn't we use the same fix in this case too?
^ permalink raw reply [flat|nested] 205+ messages in thread
[parent not found: <5329F296.6030308-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>]
* Re: [PATCH 62/62] ARM: tegra: make debug_ll code build for ARMv6
2014-03-19 19:40 ` Stephen Warren
@ 2014-03-19 19:51 ` Arnd Bergmann
-1 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:51 UTC (permalink / raw)
To: Stephen Warren
Cc: arm-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thierry Reding, linux-tegra-u79uwXL29TY76Z2rM5mHXA
On Wednesday 19 March 2014 13:40:06 Stephen Warren wrote:
> Hmmm. This code is guaranteed to only execute on Tegra (well, perhaps
> someone can turn on the wrong debug option and run it on non-Tegra, but
> then it's guaranteed not to work since the HW it touches doesn't exist).
> As such, the code ought to be able to use ARMv7 instructions.
>
> As a fix for similar issues in assembly code in arch/arm/mach-tegra/*.S,
> Makefile there does:
>
> asflags-y += -march=armv7-a
>
> (I think you added that? Yes, in 408e713545ca "ARM: tegra: build
> assembly files with -march=armv7-a")
>
> Shouldn't we use the same fix in this case too?
That was my first idea, but I couldn't come up with a nice way to do this
for arch/arm/kernel/debug.S, which #includes the specific implementation.
I'd rather not put lots of per-platform hacks into arch/arm/kernel/Makefile.
Arnd
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 62/62] ARM: tegra: make debug_ll code build for ARMv6
@ 2014-03-19 19:51 ` Arnd Bergmann
0 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-19 19:51 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 19 March 2014 13:40:06 Stephen Warren wrote:
> Hmmm. This code is guaranteed to only execute on Tegra (well, perhaps
> someone can turn on the wrong debug option and run it on non-Tegra, but
> then it's guaranteed not to work since the HW it touches doesn't exist).
> As such, the code ought to be able to use ARMv7 instructions.
>
> As a fix for similar issues in assembly code in arch/arm/mach-tegra/*.S,
> Makefile there does:
>
> asflags-y += -march=armv7-a
>
> (I think you added that? Yes, in 408e713545ca "ARM: tegra: build
> assembly files with -march=armv7-a")
>
> Shouldn't we use the same fix in this case too?
That was my first idea, but I couldn't come up with a nice way to do this
for arch/arm/kernel/debug.S, which #includes the specific implementation.
I'd rather not put lots of per-platform hacks into arch/arm/kernel/Makefile.
Arnd
^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: [PATCH 62/62] ARM: tegra: make debug_ll code build for ARMv6
2014-03-19 19:51 ` Arnd Bergmann
@ 2014-03-19 20:12 ` Stephen Warren
-1 siblings, 0 replies; 205+ messages in thread
From: Stephen Warren @ 2014-03-19 20:12 UTC (permalink / raw)
To: Arnd Bergmann
Cc: arm-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thierry Reding, linux-tegra-u79uwXL29TY76Z2rM5mHXA
On 03/19/2014 01:51 PM, Arnd Bergmann wrote:
> On Wednesday 19 March 2014 13:40:06 Stephen Warren wrote:
>> Hmmm. This code is guaranteed to only execute on Tegra (well, perhaps
>> someone can turn on the wrong debug option and run it on non-Tegra, but
>> then it's guaranteed not to work since the HW it touches doesn't exist).
>> As such, the code ought to be able to use ARMv7 instructions.
>>
>> As a fix for similar issues in assembly code in arch/arm/mach-tegra/*.S,
>> Makefile there does:
>>
>> asflags-y += -march=armv7-a
>>
>> (I think you added that? Yes, in 408e713545ca "ARM: tegra: build
>> assembly files with -march=armv7-a")
>>
>> Shouldn't we use the same fix in this case too?
>
> That was my first idea, but I couldn't come up with a nice way to do this
> for arch/arm/kernel/debug.S, which #includes the specific implementation.
>
> I'd rather not put lots of per-platform hacks into arch/arm/kernel/Makefile.
Oh, I guess the fact it's include makes it a bit more painful.
You could deal with it in Kconfig reasonably easily by having each of
DEBUG_*_UART select a config option indicating how to compile code that
includes DEBUG_LL_INCLUDE, and then have the Makefiles set up asflags
based on those. Still, that would be a lot of work and this patch is
simpler.
Tested-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Acked-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 62/62] ARM: tegra: make debug_ll code build for ARMv6
@ 2014-03-19 20:12 ` Stephen Warren
0 siblings, 0 replies; 205+ messages in thread
From: Stephen Warren @ 2014-03-19 20:12 UTC (permalink / raw)
To: linux-arm-kernel
On 03/19/2014 01:51 PM, Arnd Bergmann wrote:
> On Wednesday 19 March 2014 13:40:06 Stephen Warren wrote:
>> Hmmm. This code is guaranteed to only execute on Tegra (well, perhaps
>> someone can turn on the wrong debug option and run it on non-Tegra, but
>> then it's guaranteed not to work since the HW it touches doesn't exist).
>> As such, the code ought to be able to use ARMv7 instructions.
>>
>> As a fix for similar issues in assembly code in arch/arm/mach-tegra/*.S,
>> Makefile there does:
>>
>> asflags-y += -march=armv7-a
>>
>> (I think you added that? Yes, in 408e713545ca "ARM: tegra: build
>> assembly files with -march=armv7-a")
>>
>> Shouldn't we use the same fix in this case too?
>
> That was my first idea, but I couldn't come up with a nice way to do this
> for arch/arm/kernel/debug.S, which #includes the specific implementation.
>
> I'd rather not put lots of per-platform hacks into arch/arm/kernel/Makefile.
Oh, I guess the fact it's include makes it a bit more painful.
You could deal with it in Kconfig reasonably easily by having each of
DEBUG_*_UART select a config option indicating how to compile code that
includes DEBUG_LL_INCLUDE, and then have the Makefiles set up asflags
based on those. Still, that would be a lot of work and this patch is
simpler.
Tested-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
^ permalink raw reply [flat|nested] 205+ messages in thread
[parent not found: <5329FA18.6090208-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>]
* Re: [PATCH 62/62] ARM: tegra: make debug_ll code build for ARMv6
2014-03-19 20:12 ` Stephen Warren
@ 2014-03-20 10:50 ` Arnd Bergmann
-1 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-20 10:50 UTC (permalink / raw)
To: Stephen Warren
Cc: arm-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thierry Reding, linux-tegra-u79uwXL29TY76Z2rM5mHXA
On Wednesday 19 March 2014, Stephen Warren wrote:
> On 03/19/2014 01:51 PM, Arnd Bergmann wrote:
> > On Wednesday 19 March 2014 13:40:06 Stephen Warren wrote:
> >> Hmmm. This code is guaranteed to only execute on Tegra (well, perhaps
> >> someone can turn on the wrong debug option and run it on non-Tegra, but
> >> then it's guaranteed not to work since the HW it touches doesn't exist).
> >> As such, the code ought to be able to use ARMv7 instructions.
> >>
> >> As a fix for similar issues in assembly code in arch/arm/mach-tegra/*.S,
> >> Makefile there does:
> >>
> >> asflags-y += -march=armv7-a
> >>
> >> (I think you added that? Yes, in 408e713545ca "ARM: tegra: build
> >> assembly files with -march=armv7-a")
> >>
> >> Shouldn't we use the same fix in this case too?
> >
> > That was my first idea, but I couldn't come up with a nice way to do this
> > for arch/arm/kernel/debug.S, which #includes the specific implementation.
> >
> > I'd rather not put lots of per-platform hacks into arch/arm/kernel/Makefile.
>
> Oh, I guess the fact it's include makes it a bit more painful.
>
> You could deal with it in Kconfig reasonably easily by having each of
> DEBUG_*_UART select a config option indicating how to compile code that
> includes DEBUG_LL_INCLUDE, and then have the Makefiles set up asflags
> based on those. Still, that would be a lot of work and this patch is
> simpler.
>
> Tested-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> Acked-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Ok, thanks for testing! I'm always cautious aobut my own assembly skills,
so I'm glad this worked.
Arnd
^ permalink raw reply [flat|nested] 205+ messages in thread
* [PATCH 62/62] ARM: tegra: make debug_ll code build for ARMv6
@ 2014-03-20 10:50 ` Arnd Bergmann
0 siblings, 0 replies; 205+ messages in thread
From: Arnd Bergmann @ 2014-03-20 10:50 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 19 March 2014, Stephen Warren wrote:
> On 03/19/2014 01:51 PM, Arnd Bergmann wrote:
> > On Wednesday 19 March 2014 13:40:06 Stephen Warren wrote:
> >> Hmmm. This code is guaranteed to only execute on Tegra (well, perhaps
> >> someone can turn on the wrong debug option and run it on non-Tegra, but
> >> then it's guaranteed not to work since the HW it touches doesn't exist).
> >> As such, the code ought to be able to use ARMv7 instructions.
> >>
> >> As a fix for similar issues in assembly code in arch/arm/mach-tegra/*.S,
> >> Makefile there does:
> >>
> >> asflags-y += -march=armv7-a
> >>
> >> (I think you added that? Yes, in 408e713545ca "ARM: tegra: build
> >> assembly files with -march=armv7-a")
> >>
> >> Shouldn't we use the same fix in this case too?
> >
> > That was my first idea, but I couldn't come up with a nice way to do this
> > for arch/arm/kernel/debug.S, which #includes the specific implementation.
> >
> > I'd rather not put lots of per-platform hacks into arch/arm/kernel/Makefile.
>
> Oh, I guess the fact it's include makes it a bit more painful.
>
> You could deal with it in Kconfig reasonably easily by having each of
> DEBUG_*_UART select a config option indicating how to compile code that
> includes DEBUG_LL_INCLUDE, and then have the Makefiles set up asflags
> based on those. Still, that would be a lot of work and this patch is
> simpler.
>
> Tested-by: Stephen Warren <swarren@nvidia.com>
> Acked-by: Stephen Warren <swarren@nvidia.com>
Ok, thanks for testing! I'm always cautious aobut my own assembly skills,
so I'm glad this worked.
Arnd
^ permalink raw reply [flat|nested] 205+ messages in thread