ARM: orion5x/dove/mv78xx0 multiplatform
Subsystems (4)
cover ARM: orion5x/dove/mv78xx0 multiplatform
I've posted these before and now gotten around to a rebase and want to include them in the arm-soc next/multiplatform branch for 4.5.
Originally the plan for these platforms was to convert all of them to DT and use only mach-mvebu. That has not happened, so I would do it this way instead so we can at least have them in a single kernel.
Let me know if there are any concerns or objections.
Arnd Bergmann (5):
ARM: orion: move watchdog setup to mach-orion5x
ARM: orion: always use MULTI_IRQ_HANDLER
ARM: orion: use SPARSE_IRQ everywhere
ARM: orion: clean up mach/*.h headers
ARM: orion: multiplatform support
arch/arm/Kconfig | 40 ------------------
arch/arm/configs/dove_defconfig | 2 +
arch/arm/configs/mv78xx0_defconfig | 3 ++
arch/arm/configs/orion5x_defconfig | 3 ++
arch/arm/mach-dove/Kconfig | 15 +++++--
arch/arm/mach-dove/Makefile | 2 +
.../arm/mach-dove/{include/mach => }/bridge-regs.h | 4 +-
arch/arm/mach-dove/cm-a510.c | 4 +-
arch/arm/mach-dove/common.c | 4 +-
arch/arm/mach-dove/dove-db-setup.c | 3 +-
arch/arm/mach-dove/{include/mach => }/dove.h | 4 +-
arch/arm/mach-dove/include/mach/entry-macro.S | 33 ---------------
arch/arm/mach-dove/include/mach/hardware.h | 19 ---------
arch/arm/mach-dove/include/mach/uncompress.h | 36 ----------------
arch/arm/mach-dove/irq.c | 22 ++++------
arch/arm/mach-dove/{include/mach => }/irqs.h | 4 +-
arch/arm/mach-dove/mpp.c | 2 +-
arch/arm/mach-dove/pcie.c | 4 +-
arch/arm/mach-dove/{include/mach => }/pm.h | 6 +--
arch/arm/mach-mv78xx0/Kconfig | 15 +++++--
arch/arm/mach-mv78xx0/Makefile | 2 +
.../mach-mv78xx0/{include/mach => }/bridge-regs.h | 4 +-
arch/arm/mach-mv78xx0/buffalo-wxl-setup.c | 3 +-
arch/arm/mach-mv78xx0/common.c | 4 +-
arch/arm/mach-mv78xx0/db78x00-bp-setup.c | 3 +-
arch/arm/mach-mv78xx0/include/mach/entry-macro.S | 41 ------------------
arch/arm/mach-mv78xx0/include/mach/hardware.h | 14 -------
arch/arm/mach-mv78xx0/include/mach/uncompress.h | 46 ---------------------
arch/arm/mach-mv78xx0/irq.c | 35 +++++++++++++++-
arch/arm/mach-mv78xx0/{include/mach => }/irqs.h | 4 +-
arch/arm/mach-mv78xx0/mpp.c | 2 +-
arch/arm/mach-mv78xx0/{include/mach => }/mv78xx0.h | 4 +-
arch/arm/mach-mv78xx0/pcie.c | 2 +-
arch/arm/mach-mv78xx0/rd78x00-masa-setup.c | 3 +-
arch/arm/mach-orion5x/Kconfig | 18 ++++++--
arch/arm/mach-orion5x/Makefile | 2 +
arch/arm/mach-orion5x/board-d2net.c | 2 +-
arch/arm/mach-orion5x/board-dt.c | 4 +-
arch/arm/mach-orion5x/board-mss2.c | 4 +-
arch/arm/mach-orion5x/board-rd88f5182.c | 2 +-
.../mach-orion5x/{include/mach => }/bridge-regs.h | 4 +-
arch/arm/mach-orion5x/common.c | 20 +++++++--
arch/arm/mach-orion5x/db88f5281-setup.c | 3 +-
arch/arm/mach-orion5x/dns323-setup.c | 3 +-
arch/arm/mach-orion5x/include/mach/entry-macro.S | 25 -----------
arch/arm/mach-orion5x/include/mach/hardware.h | 14 -------
arch/arm/mach-orion5x/include/mach/uncompress.h | 48 ----------------------
arch/arm/mach-orion5x/irq.c | 13 +-----
arch/arm/mach-orion5x/{include/mach => }/irqs.h | 4 +-
arch/arm/mach-orion5x/kurobox_pro-setup.c | 4 +-
arch/arm/mach-orion5x/ls-chl-setup.c | 3 +-
arch/arm/mach-orion5x/ls_hgl-setup.c | 3 +-
arch/arm/mach-orion5x/mpp.c | 2 +-
arch/arm/mach-orion5x/mv2120-setup.c | 3 +-
arch/arm/mach-orion5x/net2big-setup.c | 3 +-
arch/arm/mach-orion5x/{include/mach => }/orion5x.h | 4 +-
arch/arm/mach-orion5x/pci.c | 2 +-
arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c | 3 +-
arch/arm/mach-orion5x/rd88f5181l-ge-setup.c | 3 +-
arch/arm/mach-orion5x/rd88f5182-setup.c | 3 +-
arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c | 3 +-
arch/arm/mach-orion5x/terastation_pro2-setup.c | 3 +-
arch/arm/mach-orion5x/ts209-setup.c | 3 +-
arch/arm/mach-orion5x/ts409-setup.c | 3 +-
arch/arm/mach-orion5x/ts78xx-setup.c | 3 +-
arch/arm/mach-orion5x/tsx09-common.c | 2 +-
arch/arm/mach-orion5x/wnr854t-setup.c | 3 +-
arch/arm/mach-orion5x/wrt350n-v2-setup.c | 3 +-
arch/arm/plat-orion/common.c | 21 ----------
arch/arm/plat-orion/include/plat/common.h | 2 -
arch/arm/plat-orion/irq.c | 1 -
arch/arm/plat-orion/mpp.c | 1 -
72 files changed, 185 insertions(+), 454 deletions(-)
rename arch/arm/mach-dove/{include/mach => }/bridge-regs.h (96%)
rename arch/arm/mach-dove/{include/mach => }/dove.h (99%)
delete mode 100644 arch/arm/mach-dove/include/mach/entry-macro.S
delete mode 100644 arch/arm/mach-dove/include/mach/hardware.h
delete mode 100644 arch/arm/mach-dove/include/mach/uncompress.h
rename arch/arm/mach-dove/{include/mach => }/irqs.h (96%)
rename arch/arm/mach-dove/{include/mach => }/pm.h (95%)
rename arch/arm/mach-mv78xx0/{include/mach => }/bridge-regs.h (92%)
delete mode 100644 arch/arm/mach-mv78xx0/include/mach/entry-macro.S
delete mode 100644 arch/arm/mach-mv78xx0/include/mach/hardware.h
delete mode 100644 arch/arm/mach-mv78xx0/include/mach/uncompress.h
rename arch/arm/mach-mv78xx0/{include/mach => }/irqs.h (95%)
rename arch/arm/mach-mv78xx0/{include/mach => }/mv78xx0.h (98%)
rename arch/arm/mach-orion5x/{include/mach => }/bridge-regs.h (92%)
delete mode 100644 arch/arm/mach-orion5x/include/mach/entry-macro.S
delete mode 100644 arch/arm/mach-orion5x/include/mach/hardware.h
delete mode 100644 arch/arm/mach-orion5x/include/mach/uncompress.h
rename arch/arm/mach-orion5x/{include/mach => }/irqs.h (94%)
rename arch/arm/mach-orion5x/{include/mach => }/orion5x.h (99%)Signature · 1 line
2.1.0.rc2
PATCH 1/5 ARM: orion: move watchdog setup to mach-orion5x
The watchdog device node is created in plat-orion/common.c but depends on the bridge address that is platform specific, so as a preparation for orion multiplatform support, we should move it out of the common code into orion5x.
The other two users of plat-orion currently do not support the watchdog device, so this is not a problem.
--- arch/arm/mach-orion5x/common.c | 14 +++++++++++++- arch/arm/plat-orion/common.c | 21 --------------------- arch/arm/plat-orion/include/plat/common.h | 2 -- 3 files changed, 13 insertions(+), 24 deletions(-)
arch/arm/mach-orion5x/common.c +13 -1
@@ -184,9 +184,21 @@ static void __init orion5x_crypto_init(void)/***************************************************************************** * Watchdog ****************************************************************************/ +static struct resource orion_wdt_resource[] = { +DEFINE_RES_MEM (TIMER_PHYS_BASE ,0x04 ), +DEFINE_RES_MEM (RSTOUTn_MASK_PHYS,0x04 ), +}; + +static struct platform_device orion_wdt_device = { + .name ="orion_wdt" , + .id =-1 , + .num_resources =ARRAY_SIZE (orion_wdt_resource), + .resource = orion_wdt_resource, +}; +static void __init orion5x_wdt_init (void ) { -orion_wdt_init (); +platform_device_register (&orion_wdt_device); }
arch/arm/plat-orion/common.c +0 -21
@@ -21,7 +21,6 @@#include <net/dsa.h> #include <linux/platform_data/dma-mv_xor.h> #include <linux/platform_data/usb-ehci-orion.h> -#include <mach/bridge-regs.h> #include <plat/common.h> /* Create a clkdev entry for a given device/clk */
@@ -589,26 +588,6 @@ void __init orion_spi_1_init(unsigned long mapbase) }/***************************************************************************** -* Watchdog -****************************************************************************/ -static struct resource orion_wdt_resource[] = { -DEFINE_RES_MEM (TIMER_PHYS_BASE ,0x04 ), -DEFINE_RES_MEM (RSTOUTn_MASK_PHYS,0x04 ), -}; - -static struct platform_device orion_wdt_device = { - .name ="orion_wdt" , - .id =-1 , - .num_resources =ARRAY_SIZE (orion_wdt_resource), - .resource = orion_wdt_resource, -}; - -void __init orion_wdt_init (void ) -{ -platform_device_register (&orion_wdt_device); -} - -/***************************************************************************** * XOR ****************************************************************************/ static u64 orion_xor_dmamask =DMA_BIT_MASK (32 );
arch/arm/plat-orion/include/plat/common.h +0 -2
@@ -75,8 +75,6 @@ void __init orion_spi_init(unsigned long mapbase);void __init orion_spi_1_init (unsigned long mapbase); -void __init orion_wdt_init (void ); - void __init orion_xor0_init(unsigned long mapbase_low, unsigned long mapbase_high, unsigned long irq_0,
Signature · 1 line
2.1.0.rc2
PATCH 2/5 ARM: orion: always use MULTI_IRQ_HANDLER
In reply to Arnd BergmannAs a preparation for multiplatform support, this enables the MULTI_IRQ_HANDLER code unconditionally on dove and orion5x, and introduces the respective code on mv78xx0, which did not have it so far. The classic entry-macro.S files are removed as they are now obsolete.
--- arch/arm/Kconfig | 3 ++ arch/arm/mach-dove/include/mach/entry-macro.S | 33 ------------------- arch/arm/mach-dove/irq.c | 12 +------ arch/arm/mach-mv78xx0/include/mach/entry-macro.S | 41 ------------------------ arch/arm/mach-mv78xx0/irq.c | 33 +++++++++++++++++++ arch/arm/mach-orion5x/include/mach/entry-macro.S | 25 --------------- arch/arm/mach-orion5x/irq.c | 11 ------- 7 files changed, 37 insertions(+), 121 deletions(-) delete mode 100644 arch/arm/mach-dove/include/mach/entry-macro.S delete mode 100644 arch/arm/mach-mv78xx0/include/mach/entry-macro.S delete mode 100644 arch/arm/mach-orion5x/include/mach/entry-macro.S
arch/arm/Kconfig +3 -0
@@ -468,6 +468,7 @@ config ARCH_DOVE select CPU_PJ4 select GENERIC_CLOCKEVENTS select MIGHT_HAVE_PCI + select MULTI_IRQ_HANDLER select MVEBU_MBUS select PINCTRL select PINCTRL_DOVE
@@ -481,6 +482,7 @@ config ARCH_MV78XX0 select CPU_FEROCEON select GENERIC_CLOCKEVENTS select MVEBU_MBUS + select MULTI_IRQ_HANDLER select PCI select PLAT_ORION_LEGACY help
@@ -494,6 +496,7 @@ config ARCH_ORION5X select CPU_FEROCEON select GENERIC_CLOCKEVENTS select MVEBU_MBUS + select MULTI_IRQ_HANDLER select PCI select PLAT_ORION_LEGACY select MULTI_IRQ_HANDLER
arch/arm/mach-dove/include/mach/entry-macro.S deleted +0 -33
@@ -1,33 +0,0 @@ -/* - * arch/arm/mach-dove/include/mach/entry-macro.S - * - * Low-level IRQ helper macros for Marvell Dove platforms - * - * This file is licensed under the terms of the GNU General Public - * License version 2. This program is licensed "as is" without any - * warranty of any kind, whether express or implied. - */ - -#include <mach/bridge-regs.h> - - .macro get_irqnr_preamble, base, tmp - ldr \base, =IRQ_VIRT_BASE - .endm - - .macro get_irqnr_and_base, irqnr, irqstat, base, tmp - @ check low interrupts - ldr \irqstat, [\base, #IRQ_CAUSE_LOW_OFF] - ldr \tmp, [\base, #IRQ_MASK_LOW_OFF] - mov \irqnr, #31 - ands \irqstat, \irqstat, \tmp - - @ if no low interrupts set, check high interrupts - ldreq \irqstat, [\base, #IRQ_CAUSE_HIGH_OFF] - ldreq \tmp, [\base, #IRQ_MASK_HIGH_OFF] - moveq \irqnr, #63 - andeqs \irqstat, \irqstat, \tmp - - @ find first active interrupt source - clzne \irqstat, \irqstat - subne \irqnr, \irqnr, \irqstat - .endm
arch/arm/mach-dove/irq.c +1 -11
@@ -13,6 +13,7 @@#include <linux/irq.h> #include <linux/gpio.h> #include <linux/io.h> +#include <asm/exception.h> #include <asm/mach/arch.h> #include <plat/irq.h> #include <asm/mach/irq.h>
@@ -109,14 +110,6 @@ static int __initdata gpio2_irqs[4] = { 0, }; -#ifdef CONFIG_MULTI_IRQ_HANDLER -/* -* Compiling with both non-DT and DT support enabled, will -* break asm irq handler used by non-DT boards. Therefore, -* we provide a C-style irq handler even for non-DT boards, -* if MULTI_IRQ_HANDLER is set. -*/ -static void __iomem *dove_irq_base =IRQ_VIRT_BASE ;static asmlinkage void
@@ -139,7 +132,6 @@ __exception_irq_entry dove_legacy_handle_irq(struct pt_regs *regs)return ; } } -#endif void __init dove_init_irq (void ) {
@@ -148,9 +140,7 @@ void __init dove_init_irq(void)orion_irq_init (1 ,IRQ_VIRT_BASE +IRQ_MASK_LOW_OFF );orion_irq_init (33 ,IRQ_VIRT_BASE +IRQ_MASK_HIGH_OFF ); -#ifdef CONFIG_MULTI_IRQ_HANDLER set_handle_irq (dove_legacy_handle_irq); -#endif /* * Initialize gpiolib for GPIOs 0-71.
arch/arm/mach-mv78xx0/include/mach/entry-macro.S deleted +0 -41
41 lines not on this page · raw message
arch/arm/mach-mv78xx0/irq.c +33 -0
@@ -11,6 +11,7 @@#include <linux/kernel.h> #include <linux/irq.h> #include <linux/io.h> +#include <asm/exception.h> #include <mach/bridge-regs.h> #include <plat/orion-gpio.h> #include <plat/irq.h>
@@ -23,12 +24,44 @@ static int __initdata gpio0_irqs[4] = { IRQ_MV78XX0_GPIO_24_31, }; +static void __iomem *mv78xx0_irq_base =IRQ_VIRT_BASE ; + +static asmlinkage void +__exception_irq_entry mv78xx0_legacy_handle_irq (struct pt_regs *regs) +{ +u32 stat; + + stat =readl_relaxed (mv78xx0_irq_base +IRQ_CAUSE_LOW_OFF ); + stat &=readl_relaxed (mv78xx0_irq_base +IRQ_MASK_LOW_OFF ); +if (stat) { +unsigned int hwirq =__fls (stat); +handle_IRQ (hwirq, regs); +return ; + } + stat =readl_relaxed (mv78xx0_irq_base +IRQ_CAUSE_HIGH_OFF ); + stat &=readl_relaxed (mv78xx0_irq_base +IRQ_MASK_HIGH_OFF ); +if (stat) { +unsigned int hwirq =32 +__fls (stat); +handle_IRQ (hwirq, regs); +return ; + } + stat =readl_relaxed (mv78xx0_irq_base +IRQ_CAUSE_ERR_OFF ); + stat &=readl_relaxed (mv78xx0_irq_base +IRQ_MASK_ERR_OFF ); +if (stat) { +unsigned int hwirq =64 +__fls (stat); +handle_IRQ (hwirq, regs); +return ; + } +} +void __init mv78xx0_init_irq (void ) {orion_irq_init (0 ,IRQ_VIRT_BASE +IRQ_MASK_LOW_OFF );orion_irq_init (32 ,IRQ_VIRT_BASE +IRQ_MASK_HIGH_OFF );orion_irq_init (64 ,IRQ_VIRT_BASE +IRQ_MASK_ERR_OFF ); +set_handle_irq (mv78xx0_legacy_handle_irq); +/* * Initialize gpiolib for GPIOs 0-31. (The GPIO interrupt mask * registers for core #1 are at an offset of 0x18 from those of
arch/arm/mach-orion5x/include/mach/entry-macro.S deleted +0 -25
@@ -1,25 +0,0 @@ -/* - * arch/arm/mach-orion5x/include/mach/entry-macro.S - * - * Low-level IRQ helper macros for Orion platforms - * - * This file is licensed under the terms of the GNU General Public - * License version 2. This program is licensed "as is" without any - * warranty of any kind, whether express or implied. - */ - -#include <mach/bridge-regs.h> - - .macro get_irqnr_preamble, base, tmp - ldr \base, =MAIN_IRQ_CAUSE - .endm - - .macro get_irqnr_and_base, irqnr, irqstat, base, tmp - ldr \irqstat, [\base, #0] @ main cause - ldr \tmp, [\base, #(MAIN_IRQ_MASK - MAIN_IRQ_CAUSE)] @ main mask - mov \irqnr, #0 @ default irqnr - @ find cause bits that are unmasked - ands \irqstat, \irqstat, \tmp @ clear Z flag if any - clzne \irqnr, \irqstat @ calc irqnr - rsbne \irqnr, \irqnr, #31 - .endm
arch/arm/mach-orion5x/irq.c +0 -11
@@ -26,14 +26,6 @@ static int __initdata gpio0_irqs[4] = { IRQ_ORION5X_GPIO_24_31, }; -#ifdef CONFIG_MULTI_IRQ_HANDLER -/* -* Compiling with both non-DT and DT support enabled, will -* break asm irq handler used by non-DT boards. Therefore, -* we provide a C-style irq handler even for non-DT boards, -* if MULTI_IRQ_HANDLER is set. -*/ - asmlinkage void__exception_irq_entry orion5x_legacy_handle_irq (struct pt_regs *regs) {
@@ -47,15 +39,12 @@ __exception_irq_entry orion5x_legacy_handle_irq(struct pt_regs *regs)return ; } } -#endif void __init orion5x_init_irq (void ) {orion_irq_init (1 ,MAIN_IRQ_MASK ); -#ifdef CONFIG_MULTI_IRQ_HANDLER set_handle_irq (orion5x_legacy_handle_irq); -#endif /* * Initialize gpiolib for GPIOs 0-31.
Signature · 1 line
2.1.0.rc2
PATCH 3/5 ARM: orion: use SPARSE_IRQ everywhere
In reply to Arnd BergmannAs a preparation for multiplatform support, this moves all the code using plat-orion over to use sparse irq support, which is enabled implicitly for multiplatform.
In particular, the hardcoded NR_IRQS macro gets replaced with a machine specific one that is set in the machine descriptor in order to set up a static mapping for all legacy interrupts.
--- arch/arm/Kconfig | 3 +++ arch/arm/mach-dove/cm-a510.c | 1 + arch/arm/mach-dove/dove-db-setup.c | 1 + arch/arm/mach-dove/include/mach/dove.h | 2 ++ arch/arm/mach-dove/include/mach/irqs.h | 2 +- arch/arm/mach-dove/include/mach/pm.h | 2 +- arch/arm/mach-dove/irq.c | 2 +- arch/arm/mach-mv78xx0/buffalo-wxl-setup.c | 1 + arch/arm/mach-mv78xx0/db78x00-bp-setup.c | 1 + arch/arm/mach-mv78xx0/include/mach/irqs.h | 2 +- arch/arm/mach-mv78xx0/include/mach/mv78xx0.h | 2 ++ arch/arm/mach-mv78xx0/rd78x00-masa-setup.c | 1 + arch/arm/mach-orion5x/db88f5281-setup.c | 1 + arch/arm/mach-orion5x/dns323-setup.c | 1 + arch/arm/mach-orion5x/include/mach/irqs.h | 2 +- arch/arm/mach-orion5x/include/mach/orion5x.h | 2 ++ arch/arm/mach-orion5x/kurobox_pro-setup.c | 2 ++ arch/arm/mach-orion5x/ls-chl-setup.c | 1 + arch/arm/mach-orion5x/ls_hgl-setup.c | 1 + arch/arm/mach-orion5x/mv2120-setup.c | 1 + arch/arm/mach-orion5x/net2big-setup.c | 1 + arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c | 1 + arch/arm/mach-orion5x/rd88f5181l-ge-setup.c | 1 + arch/arm/mach-orion5x/rd88f5182-setup.c | 1 + arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c | 1 + arch/arm/mach-orion5x/terastation_pro2-setup.c | 1 + arch/arm/mach-orion5x/ts209-setup.c | 1 + arch/arm/mach-orion5x/ts409-setup.c | 1 + arch/arm/mach-orion5x/ts78xx-setup.c | 1 + arch/arm/mach-orion5x/wnr854t-setup.c | 1 + arch/arm/mach-orion5x/wrt350n-v2-setup.c | 1 + 31 files changed, 37 insertions(+), 5 deletions(-)
arch/arm/Kconfig +3 -0
@@ -473,6 +473,7 @@ config ARCH_DOVE select PINCTRL select PINCTRL_DOVE select PLAT_ORION_LEGACY + select SPARSE_IRQ help Support for the Marvell Dove SoC 88AP510
@@ -485,6 +486,7 @@ config ARCH_MV78XX0 select MULTI_IRQ_HANDLER select PCI select PLAT_ORION_LEGACY + select SPARSE_IRQ help Support for the following Marvell MV78xx0 series SoCs: MV781x0, MV782x0.
@@ -500,6 +502,7 @@ config ARCH_ORION5X select PCI select PLAT_ORION_LEGACY select MULTI_IRQ_HANDLER + select SPARSE_IRQ help Support for the following Marvell Orion 5x series SoCs: Orion-1 (5181), Orion-VoIP (5181L), Orion-NAS (5182),
arch/arm/mach-dove/cm-a510.c +1 -0
@@ -88,6 +88,7 @@ static void __init cm_a510_init(void)MACHINE_START (CM_A510 ,"Compulab CM-A510 Board" ) .atag_offset = 0x100, + .nr_irqs = DOVE_NR_IRQS, .init_machine = cm_a510_init, .map_io = dove_map_io, .init_early = dove_init_early,
arch/arm/mach-dove/dove-db-setup.c +1 -0
@@ -94,6 +94,7 @@ static void __init dove_db_init(void)MACHINE_START (DOVE_DB ,"Marvell DB-MV88AP510-BP Development Board" ) .atag_offset = 0x100, + .nr_irqs = DOVE_NR_IRQS, .init_machine = dove_db_init, .map_io = dove_map_io, .init_early = dove_init_early,
arch/arm/mach-dove/include/mach/dove.h +2 -0
@@ -11,6 +11,8 @@#ifndef __ASM_ARCH_DOVE_H#define __ASM_ARCH_DOVE_H +#include <mach/irqs.h> +/* * Marvell Dove address maps. *
arch/arm/mach-dove/include/mach/irqs.h +1 -1
@@ -90,7 +90,7 @@#define NR_PMU_IRQS 7#define IRQ_DOVE_RTC (IRQ_DOVE_PMU_START + 5) -#define NR_IRQS (IRQ_DOVE_PMU_START + NR_PMU_IRQS) +#define DOVE_NR_IRQS (IRQ_DOVE_PMU_START + NR_PMU_IRQS)#endif
arch/arm/mach-dove/include/mach/pm.h +1 -1
@@ -63,7 +63,7 @@ static inline int pmu_to_irq(int pin)static inline int irq_to_pmu (int irq) { -if (IRQ_DOVE_PMU_START <= irq && irq <NR_IRQS ) +if (IRQ_DOVE_PMU_START <= irq && irq <DOVE_NR_IRQS )return irq -IRQ_DOVE_PMU_START ;return -EINVAL ;
arch/arm/mach-dove/irq.c +1 -1
@@ -160,7 +160,7 @@ void __init dove_init_irq(void)writel (0 ,PMU_INTERRUPT_MASK );writel (0 ,PMU_INTERRUPT_CAUSE ); -for (i =IRQ_DOVE_PMU_START ; i <NR_IRQS ; i++) { +for (i =IRQ_DOVE_PMU_START ; i <DOVE_NR_IRQS ; i++) {irq_set_chip_and_handler (i, &pmu_irq_chip, handle_level_irq);irq_set_status_flags (i,IRQ_LEVEL );irq_clear_status_flags (i,IRQ_NOREQUEST );
arch/arm/mach-mv78xx0/buffalo-wxl-setup.c +1 -0
@@ -146,6 +146,7 @@ subsys_initcall(wxl_pci_init);MACHINE_START (TERASTATION_WXL ,"Buffalo Nas WXL" )/* Maintainer: Sebastien Requiem <[email protected]> */ .atag_offset = 0x100, + .nr_irqs = MV78XX0_NR_IRQS, .init_machine = wxl_init, .map_io = mv78xx0_map_io, .init_early = mv78xx0_init_early,
arch/arm/mach-mv78xx0/db78x00-bp-setup.c +1 -0
@@ -94,6 +94,7 @@ subsys_initcall(db78x00_pci_init);MACHINE_START (DB78X00_BP ,"Marvell DB-78x00-BP Development Board" )/* Maintainer: Lennert Buytenhek <[email protected]> */ .atag_offset = 0x100, + .nr_irqs = MV78XX0_NR_IRQS, .init_machine = db78x00_init, .map_io = mv78xx0_map_io, .init_early = mv78xx0_init_early,
arch/arm/mach-mv78xx0/include/mach/irqs.h +1 -1
@@ -88,7 +88,7 @@#define IRQ_MV78XX0_GPIO_START 96#define NR_GPIO_IRQS 32 -#define NR_IRQS (IRQ_MV78XX0_GPIO_START + NR_GPIO_IRQS) +#define MV78XX0_NR_IRQS (IRQ_MV78XX0_GPIO_START + NR_GPIO_IRQS)#endif
arch/arm/mach-mv78xx0/include/mach/mv78xx0.h +2 -0
@@ -12,6 +12,8 @@#ifndef __ASM_ARCH_MV78XX0_H#define __ASM_ARCH_MV78XX0_H +#include "irqs.h" +/* * Marvell MV78xx0 address maps. *
arch/arm/mach-mv78xx0/rd78x00-masa-setup.c +1 -0
@@ -79,6 +79,7 @@ subsys_initcall(rd78x00_pci_init);MACHINE_START (RD78X00_MASA ,"Marvell RD-78x00-MASA Development Board" )/* Maintainer: Lennert Buytenhek <[email protected]> */ .atag_offset = 0x100, + .nr_irqs = MV78XX0_NR_IRQS, .init_machine = rd78x00_masa_init, .map_io = mv78xx0_map_io, .init_early = mv78xx0_init_early,
arch/arm/mach-orion5x/db88f5281-setup.c +1 -0
@@ -369,6 +369,7 @@ static void __init db88f5281_init(void)MACHINE_START (DB88F5281 ,"Marvell Orion-2 Development Board" )/* Maintainer: Tzachi Perelstein <[email protected]> */ .atag_offset = 0x100, + .nr_irqs = ORION5X_NR_IRQS, .init_machine = db88f5281_init, .map_io = orion5x_map_io, .init_early = orion5x_init_early,
arch/arm/mach-orion5x/dns323-setup.c +1 -0
@@ -666,6 +666,7 @@ static void __init dns323_init(void)MACHINE_START (DNS323 ,"D-Link DNS-323" )/* Maintainer: Herbert Valerio Riedel <[email protected]> */ .atag_offset = 0x100, + .nr_irqs = ORION5X_NR_IRQS, .init_machine = dns323_init, .map_io = orion5x_map_io, .init_early = orion5x_init_early,
arch/arm/mach-orion5x/include/mach/irqs.h +1 -1
@@ -54,7 +54,7 @@#define IRQ_ORION5X_GPIO_START 33#define NR_GPIO_IRQS 32 -#define NR_IRQS (IRQ_ORION5X_GPIO_START + NR_GPIO_IRQS) +#define ORION5X_NR_IRQS (IRQ_ORION5X_GPIO_START + NR_GPIO_IRQS)#endif
arch/arm/mach-orion5x/include/mach/orion5x.h +2 -0
@@ -14,6 +14,8 @@#ifndef __ASM_ARCH_ORION5X_H#define __ASM_ARCH_ORION5X_H +#include <mach/irqs.h> +/***************************************************************************** * Orion Address Maps *
arch/arm/mach-orion5x/kurobox_pro-setup.c +2 -0
@@ -383,6 +383,7 @@ static void __init kurobox_pro_init(void)MACHINE_START (KUROBOX_PRO ,"Buffalo/Revogear Kurobox Pro" )/* Maintainer: Ronen Shitrit <[email protected]> */ .atag_offset = 0x100, + .nr_irqs = ORION5X_NR_IRQS, .init_machine = kurobox_pro_init, .map_io = orion5x_map_io, .init_early = orion5x_init_early,
@@ -397,6 +398,7 @@ MACHINE_ENDMACHINE_START (LINKSTATION_PRO ,"Buffalo Linkstation Pro/Live" )/* Maintainer: Byron Bradley <[email protected]> */ .atag_offset = 0x100, + .nr_irqs = ORION5X_NR_IRQS, .init_machine = kurobox_pro_init, .map_io = orion5x_map_io, .init_early = orion5x_init_early,
arch/arm/mach-orion5x/ls-chl-setup.c +1 -0
@@ -320,6 +320,7 @@ static void __init lschl_init(void)MACHINE_START (LINKSTATION_LSCHL ,"Buffalo Linkstation LiveV3 (LS-CHL)" )/* Maintainer: Ash Hughes <[email protected]> */ .atag_offset = 0x100, + .nr_irqs = ORION5X_NR_IRQS, .init_machine = lschl_init, .map_io = orion5x_map_io, .init_early = orion5x_init_early,
arch/arm/mach-orion5x/ls_hgl-setup.c +1 -0
@@ -267,6 +267,7 @@ static void __init ls_hgl_init(void)MACHINE_START (LINKSTATION_LS_HGL ,"Buffalo Linkstation LS-HGL" )/* Maintainer: Zhu Qingsen <[email protected]> */ .atag_offset = 0x100, + .nr_irqs = ORION5X_NR_IRQS, .init_machine = ls_hgl_init, .map_io = orion5x_map_io, .init_early = orion5x_init_early,
arch/arm/mach-orion5x/mv2120-setup.c +1 -0
@@ -232,6 +232,7 @@ static void __init mv2120_init(void)MACHINE_START (MV2120 ,"HP Media Vault mv2120" )/* Maintainer: Martin Michlmayr <[email protected]> */ .atag_offset = 0x100, + .nr_irqs = ORION5X_NR_IRQS, .init_machine = mv2120_init, .map_io = orion5x_map_io, .init_early = orion5x_init_early,
arch/arm/mach-orion5x/net2big-setup.c +1 -0
@@ -423,6 +423,7 @@ static void __init net2big_init(void)/* Warning: LaCie use a wrong mach-type (0x20e=526) in their bootloader. */ MACHINE_START (NET2BIG ,"LaCie 2Big Network" ) .atag_offset = 0x100, + .nr_irqs = ORION5X_NR_IRQS, .init_machine = net2big_init, .map_io = orion5x_map_io, .init_early = orion5x_init_early,
arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c +1 -0
@@ -169,6 +169,7 @@ subsys_initcall(rd88f5181l_fxo_pci_init);MACHINE_START (RD88F5181L_FXO ,"Marvell Orion-VoIP FXO Reference Design" )/* Maintainer: Nicolas Pitre <[email protected]> */ .atag_offset = 0x100, + .nr_irqs = ORION5X_NR_IRQS, .init_machine = rd88f5181l_fxo_init, .map_io = orion5x_map_io, .init_early = orion5x_init_early,
arch/arm/mach-orion5x/rd88f5181l-ge-setup.c +1 -0
@@ -181,6 +181,7 @@ subsys_initcall(rd88f5181l_ge_pci_init);MACHINE_START (RD88F5181L_GE ,"Marvell Orion-VoIP GE Reference Design" )/* Maintainer: Lennert Buytenhek <[email protected]> */ .atag_offset = 0x100, + .nr_irqs = ORION5X_NR_IRQS, .init_machine = rd88f5181l_ge_init, .map_io = orion5x_map_io, .init_early = orion5x_init_early,
arch/arm/mach-orion5x/rd88f5182-setup.c +1 -0
@@ -281,6 +281,7 @@ static void __init rd88f5182_init(void)MACHINE_START (RD88F5182 ,"Marvell Orion-NAS Reference Design" )/* Maintainer: Ronen Shitrit <[email protected]> */ .atag_offset = 0x100, + .nr_irqs = ORION5X_NR_IRQS, .init_machine = rd88f5182_init, .map_io = orion5x_map_io, .init_early = orion5x_init_early,
arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c +1 -0
@@ -119,6 +119,7 @@ subsys_initcall(rd88f6183ap_ge_pci_init);MACHINE_START (RD88F6183AP_GE ,"Marvell Orion-1-90 AP GE Reference Design" )/* Maintainer: Lennert Buytenhek <[email protected]> */ .atag_offset = 0x100, + .nr_irqs = ORION5X_NR_IRQS, .init_machine = rd88f6183ap_ge_init, .map_io = orion5x_map_io, .init_early = orion5x_init_early,
arch/arm/mach-orion5x/terastation_pro2-setup.c +1 -0
@@ -359,6 +359,7 @@ static void __init tsp2_init(void)MACHINE_START (TERASTATION_PRO2 ,"Buffalo Terastation Pro II/Live" )/* Maintainer: Sylver Bruneau <[email protected]> */ .atag_offset = 0x100, + .nr_irqs = ORION5X_NR_IRQS, .init_machine = tsp2_init, .map_io = orion5x_map_io, .init_early = orion5x_init_early,
arch/arm/mach-orion5x/ts209-setup.c +1 -0
@@ -324,6 +324,7 @@ static void __init qnap_ts209_init(void)MACHINE_START (TS209 ,"QNAP TS-109/TS-209" )/* Maintainer: Byron Bradley <[email protected]> */ .atag_offset = 0x100, + .nr_irqs = ORION5X_NR_IRQS, .init_machine = qnap_ts209_init, .map_io = orion5x_map_io, .init_early = orion5x_init_early,
arch/arm/mach-orion5x/ts409-setup.c +1 -0
@@ -313,6 +313,7 @@ static void __init qnap_ts409_init(void)MACHINE_START (TS409 ,"QNAP TS-409" )/* Maintainer: Sylver Bruneau <[email protected]> */ .atag_offset = 0x100, + .nr_irqs = ORION5X_NR_IRQS, .init_machine = qnap_ts409_init, .map_io = orion5x_map_io, .init_early = orion5x_init_early,
arch/arm/mach-orion5x/ts78xx-setup.c +1 -0
@@ -615,6 +615,7 @@ static void __init ts78xx_init(void)MACHINE_START (TS78XX ,"Technologic Systems TS-78xx SBC" )/* Maintainer: Alexander Clouter <[email protected]> */ .atag_offset = 0x100, + .nr_irqs = ORION5X_NR_IRQS, .init_machine = ts78xx_init, .map_io = ts78xx_map_io, .init_early = orion5x_init_early,
arch/arm/mach-orion5x/wnr854t-setup.c +1 -0
@@ -174,6 +174,7 @@ subsys_initcall(wnr854t_pci_init);MACHINE_START (WNR854T ,"Netgear WNR854T" )/* Maintainer: Imre Kaloz <[email protected]> */ .atag_offset = 0x100, + .nr_irqs = ORION5X_NR_IRQS, .init_machine = wnr854t_init, .map_io = orion5x_map_io, .init_early = orion5x_init_early,
arch/arm/mach-orion5x/wrt350n-v2-setup.c +1 -0
@@ -262,6 +262,7 @@ subsys_initcall(wrt350n_v2_pci_init);MACHINE_START (WRT350N_V2 ,"Linksys WRT350N v2" )/* Maintainer: Lennert Buytenhek <[email protected]> */ .atag_offset = 0x100, + .nr_irqs = ORION5X_NR_IRQS, .init_machine = wrt350n_v2_init, .map_io = orion5x_map_io, .init_early = orion5x_init_early,
Signature · 1 line
2.1.0.rc2
PATCH 4/5 ARM: orion: clean up mach/*.h headers
In reply to Arnd BergmannThis is a simple move of all header files that are no longer included by anything else from the include/mach directory to the platform directory itself, for mv78xx0, dove, and orion5x, as preparation for multiplatform support.
The mach/uncompress.h headers are left in place for now, and are mildly modified to be independent of the other headers. They will be removed entirely when ARCH_MULTIPLATFORM gets enabled and they become obsolete.
Rather than updating the path names inside of the comments of each header, I delete those comments to avoid having to update them again, should they get moved or copied another time.
---
arch/arm/mach-dove/{include/mach => }/bridge-regs.h | 4 +---
arch/arm/mach-dove/cm-a510.c | 3 +--
arch/arm/mach-dove/common.c | 4 ++--
arch/arm/mach-dove/dove-db-setup.c | 2 +-
arch/arm/mach-dove/{include/mach => }/dove.h | 4 +---
arch/arm/mach-dove/include/mach/hardware.h | 19 -------------------
arch/arm/mach-dove/include/mach/uncompress.h | 8 +++-----
arch/arm/mach-dove/irq.c | 8 +++++---
arch/arm/mach-dove/{include/mach => }/irqs.h | 2 --
arch/arm/mach-dove/mpp.c | 2 +-
arch/arm/mach-dove/pcie.c | 4 ++--
arch/arm/mach-dove/{include/mach => }/pm.h | 4 +---
.../arm/mach-mv78xx0/{include/mach => }/bridge-regs.h | 4 +---
arch/arm/mach-mv78xx0/buffalo-wxl-setup.c | 2 +-
arch/arm/mach-mv78xx0/common.c | 4 ++--
arch/arm/mach-mv78xx0/db78x00-bp-setup.c | 2 +-
arch/arm/mach-mv78xx0/include/mach/hardware.h | 14 --------------
arch/arm/mach-mv78xx0/include/mach/uncompress.h | 4 +---
arch/arm/mach-mv78xx0/irq.c | 2 +-
arch/arm/mach-mv78xx0/{include/mach => }/irqs.h | 2 --
arch/arm/mach-mv78xx0/mpp.c | 2 +-
arch/arm/mach-mv78xx0/{include/mach => }/mv78xx0.h | 2 --
arch/arm/mach-mv78xx0/pcie.c | 2 +-
arch/arm/mach-mv78xx0/rd78x00-masa-setup.c | 2 +-
arch/arm/mach-orion5x/board-d2net.c | 2 +-
arch/arm/mach-orion5x/board-dt.c | 4 ++--
arch/arm/mach-orion5x/board-mss2.c | 4 ++--
arch/arm/mach-orion5x/board-rd88f5182.c | 2 +-
.../arm/mach-orion5x/{include/mach => }/bridge-regs.h | 4 +---
arch/arm/mach-orion5x/common.c | 6 +++---
arch/arm/mach-orion5x/db88f5281-setup.c | 2 +-
arch/arm/mach-orion5x/dns323-setup.c | 2 +-
arch/arm/mach-orion5x/include/mach/hardware.h | 14 --------------
arch/arm/mach-orion5x/include/mach/uncompress.h | 4 +---
arch/arm/mach-orion5x/irq.c | 2 +-
arch/arm/mach-orion5x/{include/mach => }/irqs.h | 2 --
arch/arm/mach-orion5x/kurobox_pro-setup.c | 2 +-
arch/arm/mach-orion5x/ls-chl-setup.c | 2 +-
arch/arm/mach-orion5x/ls_hgl-setup.c | 2 +-
arch/arm/mach-orion5x/mpp.c | 2 +-
arch/arm/mach-orion5x/mv2120-setup.c | 2 +-
arch/arm/mach-orion5x/net2big-setup.c | 2 +-
arch/arm/mach-orion5x/{include/mach => }/orion5x.h | 4 +---
arch/arm/mach-orion5x/pci.c | 2 +-
arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c | 2 +-
arch/arm/mach-orion5x/rd88f5181l-ge-setup.c | 2 +-
arch/arm/mach-orion5x/rd88f5182-setup.c | 2 +-
arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c | 2 +-
arch/arm/mach-orion5x/terastation_pro2-setup.c | 2 +-
arch/arm/mach-orion5x/ts209-setup.c | 2 +-
arch/arm/mach-orion5x/ts409-setup.c | 2 +-
arch/arm/mach-orion5x/ts78xx-setup.c | 2 +-
arch/arm/mach-orion5x/tsx09-common.c | 2 +-
arch/arm/mach-orion5x/wnr854t-setup.c | 2 +-
arch/arm/mach-orion5x/wrt350n-v2-setup.c | 2 +-
arch/arm/plat-orion/irq.c | 1 -
arch/arm/plat-orion/mpp.c | 1 -
57 files changed, 61 insertions(+), 135 deletions(-)
rename arch/arm/mach-dove/{include/mach => }/bridge-regs.h (96%)
rename arch/arm/mach-dove/{include/mach => }/dove.h (99%)
delete mode 100644 arch/arm/mach-dove/include/mach/hardware.h
rename arch/arm/mach-dove/{include/mach => }/irqs.h (98%)
rename arch/arm/mach-dove/{include/mach => }/pm.h (97%)
rename arch/arm/mach-mv78xx0/{include/mach => }/bridge-regs.h (92%)
delete mode 100644 arch/arm/mach-mv78xx0/include/mach/hardware.h
rename arch/arm/mach-mv78xx0/{include/mach => }/irqs.h (98%)
rename arch/arm/mach-mv78xx0/{include/mach => }/mv78xx0.h (98%)
rename arch/arm/mach-orion5x/{include/mach => }/bridge-regs.h (92%)
delete mode 100644 arch/arm/mach-orion5x/include/mach/hardware.h
rename arch/arm/mach-orion5x/{include/mach => }/irqs.h (97%)
rename arch/arm/mach-orion5x/{include/mach => }/orion5x.h (98%)arch/arm/mach-dove/bridge-regs.h renamed from arch/arm/mach-dove/include/mach/bridge-regs.h +1 -3
@@ -1,6 +1,4 @@/* -* arch/arm/mach-dove/include/mach/bridge-regs.h -* * Mbus-L to Mbus Bridge Registers * * This file is licensed under the terms of the GNU General Public
@@ -11,7 +9,7 @@#ifndef __ASM_ARCH_BRIDGE_REGS_H#define __ASM_ARCH_BRIDGE_REGS_H -#include <mach/dove.h> +#include "dove.h" #define CPU_CONFIG (BRIDGE_VIRT_BASE + 0x0000)
arch/arm/mach-dove/cm-a510.c +1 -2
@@ -22,8 +22,7 @@#include <asm/mach-types.h> #include <asm/mach/arch.h> -#include <mach/dove.h> - +#include "dove.h" #include "common.h" static struct mv643xx_eth_platform_data cm_a510_ge00_data = {
arch/arm/mach-dove/common.c +2 -2
@@ -20,11 +20,11 @@#include <asm/mach/arch.h> #include <asm/mach/map.h> #include <asm/mach/time.h> -#include <mach/bridge-regs.h> -#include <mach/pm.h> #include <plat/common.h> #include <plat/irq.h> #include <plat/time.h> +#include "bridge-regs.h" +#include "pm.h" #include "common.h" /* These can go away once Dove uses the mvebu-mbus DT binding */
arch/arm/mach-dove/dove-db-setup.c +1 -1
@@ -24,7 +24,7 @@#include <linux/gpio.h> #include <asm/mach-types.h> #include <asm/mach/arch.h> -#include <mach/dove.h> +#include "dove.h" #include "common.h" static struct mv643xx_eth_platform_data dove_db_ge00_data = {
arch/arm/mach-dove/dove.h renamed from arch/arm/mach-dove/include/mach/dove.h +1 -3
@@ -1,6 +1,4 @@/* -* arch/arm/mach-dove/include/mach/dove.h -* * Generic definitions for Marvell Dove 88AP510 SoC * * This file is licensed under the terms of the GNU General Public
@@ -11,7 +9,7 @@#ifndef __ASM_ARCH_DOVE_H#define __ASM_ARCH_DOVE_H -#include <mach/irqs.h> +#include "irqs.h" /* * Marvell Dove address maps.
arch/arm/mach-dove/include/mach/hardware.h deleted +0 -19
@@ -1,19 +0,0 @@ -/* -* arch/arm/mach-dove/include/mach/hardware.h -* -* This file is licensed under the terms of the GNU General Public -* License version 2. This program is licensed "as is" without any -* warranty of any kind, whether express or implied. -*/ - -#ifndef __ASM_ARCH_HARDWARE_H -#define __ASM_ARCH_HARDWARE_H - -#include "dove.h" - -/* Macros below are required for compatibility with PXA AC'97 driver. */ -#define __REG (x) (*((volatile u32 *)((x) - DOVE_SB_REGS_PHYS_BASE + \ - DOVE_SB_REGS_VIRT_BASE))) -#define __PREG (x) (((u32)&(x)) - DOVE_SB_REGS_VIRT_BASE + \ - DOVE_SB_REGS_PHYS_BASE) -#endif
arch/arm/mach-dove/include/mach/uncompress.h +3 -5
@@ -1,15 +1,13 @@/* -* arch/arm/mach-dove/include/mach/uncompress.h -* * This file is licensed under the terms of the GNU General Public * License version 2. This program is licensed "as is" without any * warranty of any kind, whether express or implied. */ -#include <mach/dove.h> +#define UART0_PHYS_BASE (0xf1000000 + 0x12000) -#define UART_THR ((volatile unsigned char *)(DOVE_UART0_PHYS_BASE + 0x0)) -#define UART_LSR ((volatile unsigned char *)(DOVE_UART0_PHYS_BASE + 0x14)) +#define UART_THR ((volatile unsigned char *)(UART0_PHYS_BASE + 0x0)) +#define UART_LSR ((volatile unsigned char *)(UART0_PHYS_BASE + 0x14))#define LSR_THRE 0x20
arch/arm/mach-dove/irq.c +5 -3
@@ -15,11 +15,13 @@#include <linux/io.h> #include <asm/exception.h> #include <asm/mach/arch.h> -#include <plat/irq.h> #include <asm/mach/irq.h> -#include <mach/pm.h> -#include <mach/bridge-regs.h> + +#include <plat/irq.h> #include <plat/orion-gpio.h> + +#include "pm.h" +#include "bridge-regs.h" #include "common.h" static void pmu_irq_mask (struct irq_data *d)
arch/arm/mach-dove/irqs.h renamed from arch/arm/mach-dove/include/mach/irqs.h +0 -2
@@ -1,6 +1,4 @@/* -* arch/arm/mach-dove/include/mach/irqs.h -* * IRQ definitions for Marvell Dove 88AP510 SoC * * This file is licensed under the terms of the GNU General Public
arch/arm/mach-dove/mpp.c +1 -1
@@ -12,8 +12,8 @@#include <linux/gpio.h> #include <linux/io.h> #include <plat/mpp.h> -#include <mach/dove.h> #include <plat/orion-gpio.h> +#include "dove.h" #include "mpp.h" struct dove_mpp_grp {
arch/arm/mach-dove/pcie.c +2 -2
@@ -17,9 +17,9 @@#include <asm/setup.h> #include <asm/delay.h> #include <plat/pcie.h> -#include <mach/irqs.h> -#include <mach/bridge-regs.h> #include <plat/addr-map.h> +#include "irqs.h" +#include "bridge-regs.h" #include "common.h" struct pcie_port {
arch/arm/mach-dove/pm.h renamed from arch/arm/mach-dove/include/mach/pm.h +1 -3
@@ -1,6 +1,4 @@/* -* arch/arm/mach-dove/include/mach/pm.h -* * This file is licensed under the terms of the GNU General Public * License version 2. This program is licensed "as is" without any * warranty of any kind, whether express or implied.
@@ -10,7 +8,7 @@#define __ASM_ARCH_PM_H#include <asm/errno.h> -#include <mach/irqs.h> +#include "irqs.h" #define CLOCK_GATING_CONTROL (DOVE_PMU_VIRT_BASE + 0x38)#define CLOCK_GATING_BIT_USB0 0
arch/arm/mach-mv78xx0/bridge-regs.h renamed from arch/arm/mach-mv78xx0/include/mach/bridge-regs.h +1 -3
@@ -1,6 +1,4 @@/* -* arch/arm/mach-mv78xx0/include/mach/bridge-regs.h -* * This file is licensed under the terms of the GNU General Public * License version 2. This program is licensed "as is" without any * warranty of any kind, whether express or implied.
@@ -9,7 +7,7 @@#ifndef __ASM_ARCH_BRIDGE_REGS_H#define __ASM_ARCH_BRIDGE_REGS_H -#include <mach/mv78xx0.h> +#include "mv78xx0.h" #define CPU_CONTROL (BRIDGE_VIRT_BASE + 0x0104)#define L2_WRITETHROUGH 0x00020000
arch/arm/mach-mv78xx0/buffalo-wxl-setup.c +1 -1
@@ -17,9 +17,9 @@#include <linux/mv643xx_eth.h> #include <linux/ethtool.h> #include <linux/i2c.h> -#include <mach/mv78xx0.h> #include <asm/mach-types.h> #include <asm/mach/arch.h> +#include "mv78xx0.h" #include "common.h" #include "mpp.h"
arch/arm/mach-mv78xx0/common.c +2 -2
@@ -18,13 +18,13 @@#include <asm/hardware/cache-feroceon-l2.h> #include <asm/mach/map.h> #include <asm/mach/time.h> -#include <mach/mv78xx0.h> -#include <mach/bridge-regs.h> #include <linux/platform_data/usb-ehci-orion.h> #include <linux/platform_data/mtd-orion_nand.h> #include <plat/time.h> #include <plat/common.h> #include <plat/addr-map.h> +#include "mv78xx0.h" +#include "bridge-regs.h" #include "common.h" static int get_tclk (void );
arch/arm/mach-mv78xx0/db78x00-bp-setup.c +1 -1
@@ -15,9 +15,9 @@#include <linux/mv643xx_eth.h> #include <linux/ethtool.h> #include <linux/i2c.h> -#include <mach/mv78xx0.h> #include <asm/mach-types.h> #include <asm/mach/arch.h> +#include "mv78xx0.h" #include "common.h" static struct mv643xx_eth_platform_data db78x00_ge00_data = {
arch/arm/mach-mv78xx0/include/mach/hardware.h deleted +0 -14
@@ -1,14 +0,0 @@ -/* -* arch/arm/mach-mv78xx0/include/mach/hardware.h -* -* This file is licensed under the terms of the GNU General Public -* License version 2. This program is licensed "as is" without any -* warranty of any kind, whether express or implied. -*/ - -#ifndef __ASM_ARCH_HARDWARE_H -#define __ASM_ARCH_HARDWARE_H - -#include "mv78xx0.h" - -#endif
arch/arm/mach-mv78xx0/include/mach/uncompress.h +1 -3
@@ -1,14 +1,12 @@/* -* arch/arm/mach-mv78xx0/include/mach/uncompress.h -* * This file is licensed under the terms of the GNU General Public * License version 2. This program is licensed "as is" without any * warranty of any kind, whether express or implied. */ #include <linux/serial_reg.h> -#include <mach/mv78xx0.h> +#define UART0_PHYS_BASE (0xf1000000 + 0x12000)#define SERIAL_BASE ((unsigned char *)UART0_PHYS_BASE)static void putc (const char c)
arch/arm/mach-mv78xx0/irq.c +1 -1
@@ -12,9 +12,9 @@#include <linux/irq.h> #include <linux/io.h> #include <asm/exception.h> -#include <mach/bridge-regs.h> #include <plat/orion-gpio.h> #include <plat/irq.h> +#include "bridge-regs.h" #include "common.h" static int __initdata gpio0_irqs[4 ] = {
arch/arm/mach-mv78xx0/irqs.h renamed from arch/arm/mach-mv78xx0/include/mach/irqs.h +0 -2
@@ -1,6 +1,4 @@/* -* arch/arm/mach-mv78xx0/include/mach/irqs.h -* * IRQ definitions for Marvell MV78xx0 SoCs * * This file is licensed under the terms of the GNU General Public
arch/arm/mach-mv78xx0/mpp.c +1 -1
@@ -12,7 +12,7 @@#include <linux/init.h> #include <linux/io.h> #include <plat/mpp.h> -#include <mach/hardware.h> +#include "mv78xx0.h" #include "common.h" #include "mpp.h"
arch/arm/mach-mv78xx0/mv78xx0.h renamed from arch/arm/mach-mv78xx0/include/mach/mv78xx0.h +0 -2
@@ -1,6 +1,4 @@/* -* arch/arm/mach-mv78xx0/include/mach/mv78xx0.h -* * Generic definitions for Marvell MV78xx0 SoC flavors: * MV781x0 and MV782x0. *
arch/arm/mach-mv78xx0/pcie.c +1 -1
@@ -15,7 +15,7 @@#include <asm/irq.h> #include <asm/mach/pci.h> #include <plat/pcie.h> -#include <mach/mv78xx0.h> +#include "mv78xx0.h" #include "common.h" #define MV78XX0_MBUS_PCIE_MEM_TARGET (port, lane) ((port) ? 8 : 4)
arch/arm/mach-mv78xx0/rd78x00-masa-setup.c +1 -1
@@ -14,9 +14,9 @@#include <linux/ata_platform.h> #include <linux/mv643xx_eth.h> #include <linux/ethtool.h> -#include <mach/mv78xx0.h> #include <asm/mach-types.h> #include <asm/mach/arch.h> +#include "mv78xx0.h" #include "common.h" static struct mv643xx_eth_platform_data rd78x00_masa_ge00_data = {
arch/arm/mach-orion5x/board-d2net.c +1 -1
@@ -20,9 +20,9 @@#include <asm/mach-types.h> #include <asm/mach/arch.h> #include <asm/mach/pci.h> -#include <mach/orion5x.h> #include <plat/orion-gpio.h> #include "common.h" +#include "orion5x.h" /***************************************************************************** * LaCie d2 Network Info
arch/arm/mach-orion5x/board-dt.c +2 -2
@@ -20,10 +20,10 @@#include <asm/system_misc.h> #include <asm/mach/arch.h> #include <asm/mach/map.h> -#include <mach/orion5x.h> -#include <mach/bridge-regs.h> #include <plat/irq.h> #include <plat/time.h> +#include "orion5x.h" +#include "bridge-regs.h" #include "common.h" static struct of_dev_auxdata orion5x_auxdata_lookup[]__initdata = {
arch/arm/mach-orion5x/board-mss2.c +2 -2
@@ -17,8 +17,8 @@#include <asm/mach-types.h> #include <asm/mach/arch.h> #include <asm/mach/pci.h> -#include <mach/orion5x.h> -#include <mach/bridge-regs.h> +#include "orion5x.h" +#include "bridge-regs.h" #include "common.h" /*****************************************************************************
arch/arm/mach-orion5x/board-rd88f5182.c +1 -1
@@ -18,8 +18,8 @@#include <asm/mach-types.h> #include <asm/mach/arch.h> #include <asm/mach/pci.h> -#include <mach/orion5x.h> #include "common.h" +#include "orion5x.h" /***************************************************************************** * RD-88F5182 Info
arch/arm/mach-orion5x/bridge-regs.h renamed from arch/arm/mach-orion5x/include/mach/bridge-regs.h +1 -3
@@ -1,6 +1,4 @@/* -* arch/arm/mach-orion5x/include/mach/bridge-regs.h -* * Orion CPU Bridge Registers * * This file is licensed under the terms of the GNU General Public
@@ -11,7 +9,7 @@#ifndef __ASM_ARCH_BRIDGE_REGS_H#define __ASM_ARCH_BRIDGE_REGS_H -#include <mach/orion5x.h> +#include "orion5x.h" #define CPU_CONF (ORION5X_BRIDGE_VIRT_BASE + 0x100)
arch/arm/mach-orion5x/common.c +3 -3
@@ -27,14 +27,14 @@#include <asm/mach/arch.h> #include <asm/mach/map.h> #include <asm/mach/time.h> -#include <mach/bridge-regs.h> -#include <mach/hardware.h> -#include <mach/orion5x.h> #include <linux/platform_data/mtd-orion_nand.h> #include <linux/platform_data/usb-ehci-orion.h> #include <plat/time.h> #include <plat/common.h> + +#include "bridge-regs.h" #include "common.h" +#include "orion5x.h" /***************************************************************************** * I/O Address Mapping
arch/arm/mach-orion5x/db88f5281-setup.c +1 -1
@@ -23,10 +23,10 @@#include <asm/mach-types.h> #include <asm/mach/arch.h> #include <asm/mach/pci.h> -#include <mach/orion5x.h> #include <linux/platform_data/mtd-orion_nand.h> #include "common.h" #include "mpp.h" +#include "orion5x.h" /***************************************************************************** * DB-88F5281 on board devices
arch/arm/mach-orion5x/dns323-setup.c +1 -1
@@ -33,8 +33,8 @@#include <asm/mach/arch.h> #include <asm/mach/pci.h> #include <asm/system_info.h> -#include <mach/orion5x.h> #include <plat/orion-gpio.h> +#include "orion5x.h" #include "common.h" #include "mpp.h"
arch/arm/mach-orion5x/include/mach/hardware.h deleted +0 -14
@@ -1,14 +0,0 @@ -/* -* arch/arm/mach-orion5x/include/mach/hardware.h -* -* This program is free software; you can redistribute it and/or modify -* it under the terms of the GNU General Public License version 2 as -* published by the Free Software Foundation. -*/ - -#ifndef __ASM_ARCH_HARDWARE_H -#define __ASM_ARCH_HARDWARE_H - -#include "orion5x.h" - -#endif
arch/arm/mach-orion5x/include/mach/uncompress.h +1 -3
@@ -1,6 +1,4 @@/* -* arch/arm/mach-orion5x/include/mach/uncompress.h -* * Tzachi Perelstein <[email protected]> * * This file is licensed under the terms of the GNU General Public
@@ -9,8 +7,8 @@*/ #include <linux/serial_reg.h> -#include <mach/orion5x.h> +#define UART0_PHYS_BASE (0xf1000000 + 0x12000)#define SERIAL_BASE ((unsigned char *)UART0_PHYS_BASE)static void putc (const char c)
arch/arm/mach-orion5x/irq.c +1 -1
@@ -13,10 +13,10 @@#include <linux/kernel.h> #include <linux/irq.h> #include <linux/io.h> -#include <mach/bridge-regs.h> #include <plat/orion-gpio.h> #include <plat/irq.h> #include <asm/exception.h> +#include "bridge-regs.h" #include "common.h" static int __initdata gpio0_irqs[4 ] = {
arch/arm/mach-orion5x/irqs.h renamed from arch/arm/mach-orion5x/include/mach/irqs.h +0 -2
@@ -1,6 +1,4 @@/* -* arch/arm/mach-orion5x/include/mach/irqs.h -* * IRQ definitions for Orion SoC * * Maintainer: Tzachi Perelstein <[email protected]>
arch/arm/mach-orion5x/kurobox_pro-setup.c +1 -1
@@ -23,10 +23,10 @@#include <asm/mach-types.h> #include <asm/mach/arch.h> #include <asm/mach/pci.h> -#include <mach/orion5x.h> #include <linux/platform_data/mtd-orion_nand.h> #include "common.h" #include "mpp.h" +#include "orion5x.h" /***************************************************************************** * KUROBOX-PRO Info
arch/arm/mach-orion5x/ls-chl-setup.c +1 -1
@@ -22,9 +22,9 @@#include <linux/gpio.h> #include <asm/mach-types.h> #include <asm/mach/arch.h> -#include <mach/orion5x.h> #include "common.h" #include "mpp.h" +#include "orion5x.h" /***************************************************************************** * Linkstation LS-CHL Info
arch/arm/mach-orion5x/ls_hgl-setup.c +1 -1
@@ -21,9 +21,9 @@#include <linux/gpio.h> #include <asm/mach-types.h> #include <asm/mach/arch.h> -#include <mach/orion5x.h> #include "common.h" #include "mpp.h" +#include "orion5x.h" /***************************************************************************** * Linkstation LS-HGL Info
arch/arm/mach-orion5x/mpp.c +1 -1
@@ -11,8 +11,8 @@#include <linux/kernel.h> #include <linux/init.h> #include <linux/io.h> -#include <mach/hardware.h> #include <plat/mpp.h> +#include "orion5x.h" #include "mpp.h" #include "common.h"
arch/arm/mach-orion5x/mv2120-setup.c +1 -1
@@ -21,9 +21,9 @@#include <linux/ata_platform.h> #include <asm/mach-types.h> #include <asm/mach/arch.h> -#include <mach/orion5x.h> #include "common.h" #include "mpp.h" +#include "orion5x.h" #define MV2120_NOR_BOOT_BASE 0xf4000000#define MV2120_NOR_BOOT_SIZE SZ_512K
arch/arm/mach-orion5x/net2big-setup.c +1 -1
@@ -24,10 +24,10 @@#include <linux/delay.h> #include <asm/mach-types.h> #include <asm/mach/arch.h> -#include <mach/orion5x.h> #include <plat/orion-gpio.h> #include "common.h" #include "mpp.h" +#include "orion5x.h" /***************************************************************************** * LaCie 2Big Network Info
arch/arm/mach-orion5x/orion5x.h renamed from arch/arm/mach-orion5x/include/mach/orion5x.h +1 -3
@@ -1,6 +1,4 @@/* -* arch/arm/mach-orion5x/include/mach/orion5x.h -* * Generic definitions of Orion SoC flavors: * Orion-1, Orion-VoIP, Orion-NAS, Orion-2, and Orion-1-90. *
@@ -14,7 +12,7 @@#ifndef __ASM_ARCH_ORION5X_H#define __ASM_ARCH_ORION5X_H -#include <mach/irqs.h> +#include "irqs.h" /***************************************************************************** * Orion Address Maps
arch/arm/mach-orion5x/pci.c +1 -1
@@ -19,8 +19,8 @@#include <asm/mach/pci.h> #include <plat/pcie.h> #include <plat/addr-map.h> -#include <mach/orion5x.h> #include "common.h" +#include "orion5x.h" /***************************************************************************** * Orion has one PCIe controller and one PCI controller.
arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c +1 -1
@@ -20,9 +20,9 @@#include <asm/mach-types.h> #include <asm/mach/arch.h> #include <asm/mach/pci.h> -#include <mach/orion5x.h> #include "common.h" #include "mpp.h" +#include "orion5x.h" /***************************************************************************** * RD-88F5181L FXO Info
arch/arm/mach-orion5x/rd88f5181l-ge-setup.c +1 -1
@@ -21,9 +21,9 @@#include <asm/mach-types.h> #include <asm/mach/arch.h> #include <asm/mach/pci.h> -#include <mach/orion5x.h> #include "common.h" #include "mpp.h" +#include "orion5x.h" /***************************************************************************** * RD-88F5181L GE Info
arch/arm/mach-orion5x/rd88f5182-setup.c +1 -1
@@ -23,9 +23,9 @@#include <asm/mach-types.h> #include <asm/mach/arch.h> #include <asm/mach/pci.h> -#include <mach/orion5x.h> #include "common.h" #include "mpp.h" +#include "orion5x.h" /***************************************************************************** * RD-88F5182 Info
arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c +1 -1
@@ -22,8 +22,8 @@#include <asm/mach-types.h> #include <asm/mach/arch.h> #include <asm/mach/pci.h> -#include <mach/orion5x.h> #include "common.h" +#include "orion5x.h" static struct mv643xx_eth_platform_data rd88f6183ap_ge_eth_data = { .phy_addr =-1 ,
arch/arm/mach-orion5x/terastation_pro2-setup.c +1 -1
@@ -22,9 +22,9 @@#include <asm/mach-types.h> #include <asm/mach/arch.h> #include <asm/mach/pci.h> -#include <mach/orion5x.h> #include "common.h" #include "mpp.h" +#include "orion5x.h" /***************************************************************************** * Terastation Pro 2/Live Info
arch/arm/mach-orion5x/ts209-setup.c +1 -1
@@ -25,9 +25,9 @@#include <asm/mach-types.h> #include <asm/mach/arch.h> #include <asm/mach/pci.h> -#include <mach/orion5x.h> #include "common.h" #include "mpp.h" +#include "orion5x.h" #include "tsx09-common.h" #define QNAP_TS209_NOR_BOOT_BASE 0xf4000000
arch/arm/mach-orion5x/ts409-setup.c +1 -1
@@ -27,9 +27,9 @@#include <asm/mach-types.h> #include <asm/mach/arch.h> #include <asm/mach/pci.h> -#include <mach/orion5x.h> #include "common.h" #include "mpp.h" +#include "orion5x.h" #include "tsx09-common.h" /*****************************************************************************
arch/arm/mach-orion5x/ts78xx-setup.c +1 -1
@@ -23,9 +23,9 @@#include <asm/mach-types.h> #include <asm/mach/arch.h> #include <asm/mach/map.h> -#include <mach/orion5x.h> #include "common.h" #include "mpp.h" +#include "orion5x.h" #include "ts78xx-fpga.h" /*****************************************************************************
arch/arm/mach-orion5x/tsx09-common.c +1 -1
@@ -15,7 +15,7 @@#include <linux/mv643xx_eth.h> #include <linux/timex.h> #include <linux/serial_reg.h> -#include <mach/orion5x.h> +#include "orion5x.h" #include "tsx09-common.h" #include "common.h"
arch/arm/mach-orion5x/wnr854t-setup.c +1 -1
@@ -19,7 +19,7 @@#include <asm/mach-types.h> #include <asm/mach/arch.h> #include <asm/mach/pci.h> -#include <mach/orion5x.h> +#include "orion5x.h" #include "common.h" #include "mpp.h"
arch/arm/mach-orion5x/wrt350n-v2-setup.c +1 -1
@@ -22,7 +22,7 @@#include <asm/mach-types.h> #include <asm/mach/arch.h> #include <asm/mach/pci.h> -#include <mach/orion5x.h> +#include "orion5x.h" #include "common.h" #include "mpp.h"
arch/arm/plat-orion/irq.c +0 -1
@@ -18,7 +18,6 @@#include <asm/exception.h> #include <plat/irq.h> #include <plat/orion-gpio.h> -#include <mach/bridge-regs.h> void __init orion_irq_init (unsigned int irq_start,void __iomem *maskaddr) {
arch/arm/plat-orion/mpp.c +0 -1
@@ -13,7 +13,6 @@#include <linux/mbus.h> #include <linux/io.h> #include <linux/gpio.h> -#include <mach/hardware.h> #include <plat/orion-gpio.h> #include <plat/mpp.h>
Signature · 1 line
2.1.0.rc2
PATCH 5/5 ARM: orion: multiplatform support
In reply to Arnd BergmannAll three remaining orion based platforms are now ready to be enabled for multiplatform support, this patch does the switch over by modifying the Kconfig file, the defconfig and removing the last mach/*.h header that becomes obsolete with this.
--- arch/arm/Kconfig | 46 ------------------------- arch/arm/configs/dove_defconfig | 2 ++ arch/arm/configs/mv78xx0_defconfig | 3 ++ arch/arm/configs/orion5x_defconfig | 3 ++ arch/arm/mach-dove/Kconfig | 15 +++++--- arch/arm/mach-dove/Makefile | 2 ++ arch/arm/mach-dove/include/mach/uncompress.h | 34 ------------------ arch/arm/mach-mv78xx0/Kconfig | 15 +++++--- arch/arm/mach-mv78xx0/Makefile | 2 ++ arch/arm/mach-mv78xx0/include/mach/uncompress.h | 44 ----------------------- arch/arm/mach-orion5x/Kconfig | 18 +++++++--- arch/arm/mach-orion5x/Makefile | 2 ++ arch/arm/mach-orion5x/include/mach/uncompress.h | 46 ------------------------- 13 files changed, 50 insertions(+), 182 deletions(-) delete mode 100644 arch/arm/mach-dove/include/mach/uncompress.h delete mode 100644 arch/arm/mach-mv78xx0/include/mach/uncompress.h delete mode 100644 arch/arm/mach-orion5x/include/mach/uncompress.h
arch/arm/Kconfig +0 -46
@@ -462,52 +462,6 @@ config ARCH_IXP4XX help Support for Intel's IXP4XX (XScale) family of processors. -config ARCH_DOVE - bool "Marvell Dove" - select ARCH_REQUIRE_GPIOLIB - select CPU_PJ4 - select GENERIC_CLOCKEVENTS - select MIGHT_HAVE_PCI - select MULTI_IRQ_HANDLER - select MVEBU_MBUS - select PINCTRL - select PINCTRL_DOVE - select PLAT_ORION_LEGACY - select SPARSE_IRQ - help - Support for the Marvell Dove SoC 88AP510 - -config ARCH_MV78XX0 - bool "Marvell MV78xx0" - select ARCH_REQUIRE_GPIOLIB - select CPU_FEROCEON - select GENERIC_CLOCKEVENTS - select MVEBU_MBUS - select MULTI_IRQ_HANDLER - select PCI - select PLAT_ORION_LEGACY - select SPARSE_IRQ - help - Support for the following Marvell MV78xx0 series SoCs: - MV781x0, MV782x0. - -config ARCH_ORION5X - bool "Marvell Orion" - depends on MMU - select ARCH_REQUIRE_GPIOLIB - select CPU_FEROCEON - select GENERIC_CLOCKEVENTS - select MVEBU_MBUS - select MULTI_IRQ_HANDLER - select PCI - select PLAT_ORION_LEGACY - select MULTI_IRQ_HANDLER - select SPARSE_IRQ - help - Support for the following Marvell Orion 5x series SoCs: - Orion-1 (5181), Orion-VoIP (5181L), Orion-NAS (5182), - Orion-2 (5281), Orion-1-90 (6183). - config ARCH_KS8695 bool "Micrel/Kendin KS8695" select ARCH_REQUIRE_GPIOLIB
arch/arm/configs/dove_defconfig +2 -0
@@ -9,6 +9,8 @@ CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_BLK_DEV_BSG is not set CONFIG_PARTITION_ADVANCED=y +# CONFIG_ARCH_MULTI_V6 is not set +CONFIG_ARCH_MULTI_V7=y CONFIG_ARCH_DOVE=y CONFIG_MACH_DOVE_DB=y CONFIG_MACH_CM_A510=y
arch/arm/configs/mv78xx0_defconfig +3 -0
@@ -11,6 +11,9 @@ CONFIG_KPROBES=y CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_BLK_DEV_BSG is not set +CONFIG_ARCH_MULTI_V5=y +# CONFIG_ARCH_MULTI_V6 is not set +# CONFIG_ARCH_MULTI_V7 is not set CONFIG_ARCH_MV78XX0=y CONFIG_MACH_DB78X00_BP=y CONFIG_MACH_RD78X00_MASA=y
arch/arm/configs/orion5x_defconfig +3 -0
@@ -13,6 +13,9 @@ CONFIG_MODULE_UNLOAD=y # CONFIG_BLK_DEV_BSG is not set CONFIG_PARTITION_ADVANCED=y CONFIG_BSD_DISKLABEL=y +CONFIG_ARCH_MULTI_V5=y +# CONFIG_ARCH_MULTI_V6 is not set +# CONFIG_ARCH_MULTI_V7 is not set CONFIG_ARCH_ORION5X=y CONFIG_ARCH_ORION5X_DT=y CONFIG_MACH_DB88F5281=y
arch/arm/mach-dove/Kconfig +11 -4
@@ -1,6 +1,15 @@ -if ARCH_DOVE +menuconfig ARCH_DOVE + bool "Marvell Dove" if ARCH_MULTI_V7 + select ARCH_REQUIRE_GPIOLIB + select CPU_PJ4 + select MVEBU_MBUS + select PINCTRL + select PINCTRL_DOVE + select PLAT_ORION_LEGACY + help + Support for the Marvell Dove SoC 88AP510 -menu "Marvell Dove Implementations" +if ARCH_DOVE config DOVE_LEGACY bool
@@ -20,6 +29,4 @@ config MACH_CM_A510 Say 'Y' here if you want your kernel to support the CompuLab CM-A510 Board. -endmenu - endif
arch/arm/mach-dove/Makefile +2 -0
@@ -1,3 +1,5 @@ +ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/arch/arm/plat-orion/include + obj-y += common.o obj-$(CONFIG_DOVE_LEGACY) += irq.o mpp.o obj-$(CONFIG_PCI) += pcie.o
arch/arm/mach-dove/include/mach/uncompress.h deleted +0 -34
@@ -1,34 +0,0 @@ -/* -* This file is licensed under the terms of the GNU General Public -* License version 2. This program is licensed "as is" without any -* warranty of any kind, whether express or implied. -*/ - -#define UART0_PHYS_BASE (0xf1000000 + 0x12000) - -#define UART_THR ((volatile unsigned char *)(UART0_PHYS_BASE + 0x0)) -#define UART_LSR ((volatile unsigned char *)(UART0_PHYS_BASE + 0x14)) - -#define LSR_THRE 0x20 - -static void putc (const char c) -{ -int i; - -for (i =0 ; i <0x1000 ; i++) { -/* Transmit fifo not full? */ -if (*UART_LSR &LSR_THRE ) -break ; - } - - *UART_THR = c; -} - -static void flush (void ) -{ -} - -/* -* nothing to do -*/ -#define arch_decomp_setup ()
arch/arm/mach-mv78xx0/Kconfig +11 -4
@@ -1,6 +1,15 @@ -if ARCH_MV78XX0 +menuconfig ARCH_MV78XX0 + bool "Marvell MV78xx0" if ARCH_MULTI_V5 + select ARCH_REQUIRE_GPIOLIB + select CPU_FEROCEON + select MVEBU_MBUS + select PCI + select PLAT_ORION_LEGACY + help + Support for the following Marvell MV78xx0 series SoCs: + MV781x0, MV782x0. -menu "Marvell MV78xx0 Implementations" +if ARCH_MV78XX0 config MACH_DB78X00_BP bool "Marvell DB-78x00-BP Development Board"
@@ -20,6 +29,4 @@ config MACH_TERASTATION_WXL Say 'Y' here if you want your kernel to support the Buffalo WXL Nas. -endmenu - endif
arch/arm/mach-mv78xx0/Makefile +2 -0
@@ -1,3 +1,5 @@ +ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/arch/arm/plat-orion/include + obj-y += common.o mpp.o irq.o pcie.o obj-$(CONFIG_MACH_DB78X00_BP) += db78x00-bp-setup.o obj-$(CONFIG_MACH_RD78X00_MASA) += rd78x00-masa-setup.o
arch/arm/mach-mv78xx0/include/mach/uncompress.h deleted +0 -44
44 lines not on this page · raw message
arch/arm/mach-orion5x/Kconfig +14 -4
@@ -1,6 +1,18 @@ -if ARCH_ORION5X +menuconfig ARCH_ORION5X + bool "Marvell Orion" + depends on MMU && ARCH_MULTI_V5 + select ARCH_REQUIRE_GPIOLIB + select CPU_FEROCEON + select GENERIC_CLOCKEVENTS + select MVEBU_MBUS + select PCI + select PLAT_ORION_LEGACY + help + Support for the following Marvell Orion 5x series SoCs: + Orion-1 (5181), Orion-VoIP (5181L), Orion-NAS (5182), + Orion-2 (5281), Orion-1-90 (6183). -menu "Orion Implementations" +if ARCH_ORION5X config ARCH_ORION5X_DT bool "Marvell Orion5x Flattened Device Tree"
@@ -163,6 +175,4 @@ config MACH_RD88F6183AP_GE Say 'Y' here if you want your kernel to support the Marvell Orion-1-90 (88F6183) AP GE RD. -endmenu - endif
arch/arm/mach-orion5x/Makefile +2 -0
@@ -1,3 +1,5 @@ +ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/arch/arm/plat-orion/include + obj-y += common.o pci.o irq.o mpp.o obj-$(CONFIG_MACH_DB88F5281) += db88f5281-setup.o obj-$(CONFIG_MACH_RD88F5182) += rd88f5182-setup.o
arch/arm/mach-orion5x/include/mach/uncompress.h deleted +0 -46
46 lines not on this page · raw message
Signature · 1 line
2.1.0.rc2
Andrew Lunn
maintainerQuoted 10 lines · Arnd Bergmann
I've posted these before and now gotten around to a rebase and want to include them in the arm-soc next/multiplatform branch for 4.5.
Originally the plan for these platforms was to convert all of them to DT and use only mach-mvebu. That has not happened, so I would do it this way instead so we can at least have them in a single kernel.
Let me know if there are any concerns or objections.
Maybe we should just remove mv78xx0? It has been at least two years since we have heard of anybody using it, outside of Debians now replaced build system. And its IRQ handling is broken apparently.
Russell, you are the last known user of mach-dove. What are your plans? You keep saying you have given up trying to mainline your Cubox patches. Have you really given up? Can we remove mach-dove?
Orion5x is still used, we occasionally get drive-by patches.
Andrew
Hi Andrew,
Quoted 10 lines · Andrew Lunn
Quoted 9 lines · Arnd Bergmann
I've posted these before and now gotten around to a rebase and want to include them in the arm-soc next/multiplatform branch for 4.5.
Originally the plan for these platforms was to convert all of them to DT and use only mach-mvebu. That has not happened, so I would do it this way instead so we can at least have them in a single kernel.
Quoted 5 lines
Quoted 1 line
Let me know if there are any concerns or objections.
Maybe we should just remove mv78xx0? It has been at least two years since we have heard of anybody using it, outside of Debians now replaced build system. And its IRQ handling is broken apparently.
Actually I was about to remove it last year but an mv78200 user came with a bug fix on the gpio driver used by this platform:
http://marc.info/?l=linux-arm-kernel&m=140639461108781&w=2
While he seemed interseted to use a mainline kernel we don't have any news for one year:
http://marc.info/?l=linux-arm-kernel&m=141391779222342&w=2
Gregory
Signature · 4 lines
Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
Andrew Lunn
maintainerQuoted 3 lines
While he seemed interseted to use a mainline kernel we don't have any news for one year:
http://marc.info/?l=linux-arm-kernel&m=141391779222342&w=2
Maybe time for an email ping?
Andrew
Quoted 6 lines · On Wednesday 25 November 2015 18:44:54 Andrew Lunn wrote:
Quoted 3 lines
While he seemed interseted to use a mainline kernel we don't have any news for one year:
http://marc.info/?l=linux-arm-kernel&m=141391779222342&w=2Maybe time for an email ping?
I think the same discussed was what stopped my series on the last two attempts. If there are no objections to things that I'm doing, I'd suggest we just merge the multiplatform patches that we want for orion5x and dove anyway and then decide about removing mv78xx0 ;-)
Arnd
Quoted 5 lines · Arnd Bergmann
Quoted 4 lines · On Wednesday 25 November 2015 18:44:54 Andrew Lunn wrote:
Quoted 3 lines
While he seemed interseted to use a mainline kernel we don't have any news for one year:
http://marc.info/?l=linux-arm-kernel&m=141391779222342&w=2
Quoted 7 lines
Quoted 2 lines
Maybe time for an email ping?
I think the same discussed was what stopped my series on the last two attempts. If there are no objections to things that I'm doing, I'd suggest we just merge the multiplatform patches that we want for orion5x and dove anyway and then decide about removing mv78xx0 ;-)
Agreed.
thx,
Jason.
Quoted 3 lines · Andrew Lunn
Russell, you are the last known user of mach-dove. What are your plans? You keep saying you have given up trying to mainline your Cubox patches. Have you really given up? Can we remove mach-dove?
Right now, I'm developing etnaviv in spare time on the Cubox[*], which is still primarily running a non-DT kernel.
It's actually a kernel that I've hacked which is capable of booting both DT and non-DT, but even when booted in DT mode, I still require much of the arch/arm/mach-dove infrastructure to get things like armada-drm, etnaviv and other drivers running. Especially because we're missing things like the high-speed clocks (the stuff above the tclk domain.) I've not even started to work out how to get that into mainline, or how to integrate that with CCF. Quite what can be done with the audio patches, I've no idea, that remains a bone of contention and stalemate, and currently isn't DT-able. See the list of patches at the end of this message...
It feels today like I'm the only one working on improving Dove support, and so it's going to take a _long_ time to move things forward - it's likely to take years. I have many demands on my time and I have to divide it up between the various aspects.
Eg, it's taken me a whole year to get the second batch of patches for the component helper out the door... most of the time I can't see the trees for all the patches I'm carrying.
* - I'm fed up with waiting for etnaviv to mature; I've been waiting two years so far in the hope that others will do the work and finally provide everyone with a solution to the closed source userspace blob. Consequently, I don't have much time to push Dove stuff forwards right now - though it can be argued that etnaviv _is_ pushing Dove forwards. Omitting historical galcore and current etnaviv patch sets, I have 115 patches for Cubox support outstanding.
Note: some of those 115 patches have been merged during the 4.4 merge window (eg, the tda998x changes and armada drm changes) though I won't be in a position to know what the new state of affairs are until after 4.4 has been released - where upon I will (as normal) rebase my entire cubox patch set on the next released kernel.
Patch list (merges omitted)
ARM: orion: implement ARM delay timer
orion clock build fix
clk-si5351 build fix
tda998x: add cec support
cec: add tda9950 driver
cec: add HDMI CEC input driver
cec: add HDMI CEC core driver
ARM: dove: cubox-setup: add gpio table for tda998x calibration
ARM: dove: more clock cleanups
misc updates
Revert "cma debugging"
cma debugging
drm/armada: allow the primary plane to be disabled
drm: tda998x: legacy IRQ handling
enable pm domain debug
rtc: debugging
pmu: debugging
dtbsinstall: don't move target directory out of the way
mmc: hack around broken probe cleanup
ARM: add trivial IRQ handler timing debug
ARM: cubox: dt updates
ASoC: sound fixes
ARM: dove: cubox: add DT booting support
ARM: dove: cubox: add legacy Armada DRM device
ARM: dove: add Etnaviv/DRM support
ARM: dove: add VMeta support
ARM: dove: add BMM support
ARM: dove: move hwmon initialisation into PMU driver
ARM: dt: cubox: add LCD controller and TDA998x configuration
ARM: dove: add DT VMeta support
ASoC: kirkwood: cobble together audio support when DT is enabled
ASoC: kirkwood-i2s: align with mainline
ASoC: kirkwood: cobble together audio support when DT is enabled
ASoC: kirkwood: add DPCM support
ASoC: kirkwood: add spdif driver
ASoC: kirkwood: add SPDIF controls
ASoC: kirkwood: shut down external clock when not required
ARM: cubox: ensure that we indicate full regulator constraints
ARM: l2c: tauros2: fix OF-enabled non-DT boot
ARM: mvebu: allow mvebu/dove to be enabled
ARM: dove: sil clock driver build patch
ARM: dove: remove silab* files
ARM: enable SG_CHAIN for Dove
ARM: cubox: fix flash type
ARM: dove: remove cubox_extclk device
ARM: dove: clock improvements
ARM: dove: drop old vmeta power handling
ARM: dove: fix dove clock support to recalculate the actual rates
ARM: dove: cleanup dove clock support
ARM: dove: fix clock name
ARM: dove: no need for empty clock enable/disable methods
ARM: dove: remove unused clock declarations
ARM: dove: fix 'addr' types in dove clock.c
HWMON: dove: fix use if S_IRWXUGO in dove hwmon driver
HWMON: move dove hwmon module to drivers/hwmon and add MODULE_ALIAS
HWMON: dove: fix mask writes
HWMON: dove: move current_mode and warning_flag into dovetemp_data
HWMON: dove: push dovetemp_data down into functions
HWMON: dove: move timer to dovetherm_data structure
HWMON: dove: add driver private data
HWMON: dove: use module_platform_driver in dove hwmon driver
HWMON: dove: fix monitoring printks
Revert "Allow ioremap_nocache on PJ4 processor that is in Dove."
ARM: dove: convert legacy dove to PMU support
dt-bindings: add Marvell PMU documentation
VMeta: add miscdevice VMeta driver
drm/i2c: tda998x: add temporary audio configuration
drm/i2c: tda998x: add debug
drm: ensure fbdev helper arrays are appropriately dimensioned
drm/armada: start of MMP2/MMP3 support
ARM: imx6: add power domains to Vivante GPU nodes
ARM: imx6: add Vivante GPU nodes
drm/armada: move frame wait wakeup into plane work
drm/armada: convert overlay plane vbl worker to a armada plane worker
drm/armada: move CRTC flip work to primary plane work
drm/armada: move frame wait into armada_frame
drm/armada: move the locking for armada_drm_vbl_event_remove()
drm/armada: move the update of dplane->ctrl0 out of spinlock
drm/armada: move write to dma_ctrl0 to armada_drm_crtc_plane_disable()
drm/armada: provide a common helper to disable a plane
drm/armada: allocate primary plane ourselves
drm/armada: add primary plane creation
drm/armada: introduce generic armada_plane struct
drm/armada: update armada overlay to use drm_universal_plane_init()66377efa3fd4 drm/armada: use xchg() to atomically update dplane->old_fb drm/i2c: tda998x: clean up after struct tda998x_priv2 removal
drm/i2c: tda998x: kill struct tda998x_priv2
drm/i2c: tda998x: move connector into struct tda998x_priv
drm/i2c: tda998x: remove encoder pointer
drm/i2c: tda998x: remove DRM slave encoder support
drm/armada: factor out retirement of old fb
drm/armada: rename overlay identifiers
drm/armada: redo locking and atomics for armada_drm_crtc_complete_frame_work()
drm/armada: disable CRTC clock during DPMS
drm/armada: use drm_plane_force_disable() to disable the overlay plane
drm/armada: move vbl code into armada_crtc
drm/armada: remove non-component support
drm/i2c: tda998x: use more HDMI helpers
drm/i2c: tda998x: handle all outstanding interrupts
drm/i2c: tda998x: convert to u8/u16/u32 types
drm/i2c: tda998x: re-implement "Fix EDID read timeout on HDMI connect"
drm/i2c: tda998x: report whether we actually handled the IRQ
drm/i2c: tda998x: remove useless NULL checks
of: Add vendor prefix for Vivante Corporation
misc: bmm: update for v4.1 dma_buf API changes
misc: bmm: update for v3.17 dma_buf API changes
misc: add bmm_dmabuf allocator
Signature · 2 lines
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
Andrew Lunn
maintainerQuoted 4 lines
It feels today like I'm the only one working on improving Dove support, and so it's going to take a _long_ time to move things forward - it's likely to take years. I have many demands on my time and I have to divide it up between the various aspects.
Hi Russell
The problem from our side is the apparent lack of progress. We get so very few patches we wounder why we should keep it around. If there was even a steady trick of patches, we would feel better about keeping it.
So looking at this list, could you maybe post the following, if they don't have dependencies. Going from only the subject, most look simple and should not be too much effort to get mainlined.
Quoted 23 lines
orion clock build fix
ARM: dove: more clock cleanups
ARM: dove: cubox: add DT booting supportARM: dove: move hwmon initialisation into PMU driver
ARM: l2c: tauros2: fix OF-enabled non-DT boot
ARM: mvebu: allow mvebu/dove to be enabledARM: cubox: fix flash type
ARM: dove: removecubox_extclkdevice
ARM: dove: clock improvements
ARM: dove: fix dove clock support to recalculate the actual rates
ARM: dove: cleanup dove clock support
ARM: dove: fix clock name
ARM: dove: no need for empty clock enable/disable methods
ARM: dove: remove unused clock declarations
ARM: dove: fix 'addr' types in doveclock.c
HWMON: dove: fix use ifS_IRWXUGOin dove hwmon driver
HWMON: move dove hwmon module todrivers/hwmonand addMODULE_ALIAS
HWMON: dove: fix mask writes
HWMON: dove: movecurrent_modeandwarning_flagintodovetemp_data
HWMON: dove: pushdovetemp_datadown into functions
Quoted 8 lines
HWMON: dove: move timer to
dovetherm_datastructure
HWMON: dove: add driver private data
HWMON: dove: usemodule_platform_driverin dove hwmon driver
HWMON: dove: fix monitoring printks
Revert "Allowioremap_nocacheon PJ4 processor that is in Dove."
ARM: dove: convert legacy dove to PMU support
dt-bindings: add Marvell PMU documentation
of: Add vendor prefix for Vivante Corporation
Andrew
Quoted 10 lines · Andrew Lunn
Quoted 4 lines
It feels today like I'm the only one working on improving Dove support, and so it's going to take a _long_ time to move things forward - it's likely to take years. I have many demands on my time and I have to divide it up between the various aspects.
Hi Russell
The problem from our side is the apparent lack of progress. We get so very few patches we wounder why we should keep it around. If there was even a steady trick of patches, we would feel better about keeping it.
You may think there's lack of progress, but I can tell you that there's lots of progress on etnaviv right now. Since 1st November, I've authored 100 MESA patches, 81 of those merged into Christians repository. I've also been sorting out issues with the kernel side driver, which now supports cross-GPU synchronisation, necessary for iMX6, and a necessary step towards getting the kernel driver merged into mainline.
As I already explained, there is only one of me. I can only do so much, and I tend to focus on one part of the broad problem to the exclusion of other parts - I find chopping and changing all the time to be a much less efficient way of working.
Others may be able to do a little bit here, a little bit there, but I'm not like that, sorry.
I won't be able to even start thinking about looking at this stuff until next week - Arnd wants me to look at some patches he's sent out today, which I might be able to do tomorrow afternoon at the very earliest, and I'm probably not around on Friday.
See - I'm only one person, I don't have time to be able to progress lots of non-paying work at a fast rate.
You'll have to wait, just like I've had to wait to get my own patches for other stuff in, just like I have to wait for progress in other projects. Sorry, but waiting and patience is all part of open source development, especially when it relies upon volunteer effort.
Signature · 2 lines
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
Quoted 3 lines · Andrew Lunn
So looking at this list, could you maybe post the following, if they don't have dependencies. Going from only the subject, most look simple and should not be too much effort to get mainlined.
It's really not that simple. Remember what base this tree is: it is Rabeeh's kernel tree from 3.4 times, with _each_ mainline release merged into it and a patch set of 250+ patches rebased forwards. A lot of these patches do not easily apply to mainline kernels.
Quoted 1 line
Quoted 1 line
orion clock build fix
Adding linux/clk.h to plat-orion/clock.c to solve some build errors, file does not exist in mainline.
Quoted 1 line
Quoted 1 line
ARM: dove: more clock cleanups
Adding linux/clkdev.h to clk-si5351.c to fix build errors caused by 4.3 changes breaking previous tweaks to make it work in non-DT setups. Not applicable to mainline without previous tweaks.
Quoted 1 line
Quoted 1 line
ARM: dove: cubox: add DT booting support
Adds to the non-DT cubox board file a DT descriptor to pick up on the existing cubox compatible, and to hook into the "old style" initialisation to allow etnaviv/armada-drm/vmeta/bmm to work.
Quoted 1 line
Quoted 1 line
ARM: dove: move hwmon initialisation into PMU driver
Only applicable if you have the hwmon driver.
Quoted 1 line
Quoted 1 line
ARM: l2c: tauros2: fix OF-enabled non-DT boot
A possible fix for mainline if we're keeping non-DT tauros2 support around.
Quoted 1 line
Quoted 1 line
ARM: mvebu: allow mvebu/dove to be enabled
Possibly not applicable with Arnd's work.
Quoted 1 line
Quoted 1 line
ARM: cubox: fix flash type
Not applicable because mainline has no non-DT cubox board file.
Quoted 8 lines
Quoted 8 lines
ARM: dove: remove
cubox_extclkdevice
ARM: dove: clock improvements
ARM: dove: fix dove clock support to recalculate the actual rates
ARM: dove: cleanup dove clock support
ARM: dove: fix clock name
ARM: dove: no need for empty clock enable/disable methods
ARM: dove: remove unused clock declarations
ARM: dove: fix 'addr' types in doveclock.c
All the above are cleaning up the "missing bits" of the clock tree for the GPU/CPU/vmeta clocks - the stuff that's clocked off the main 2GHz PLL. No support in mainline for this, and would need to be converted to a CCF driver.
Quoted 9 lines
Quoted 9 lines
HWMON: dove: fix use if
S_IRWXUGOin dove hwmon driver
HWMON: move dove hwmon module todrivers/hwmonand addMODULE_ALIAS
HWMON: dove: fix mask writes
HWMON: dove: movecurrent_modeandwarning_flagintodovetemp_data
HWMON: dove: pushdovetemp_datadown into functions
HWMON: dove: move timer todovetherm_datastructure
HWMON: dove: add driver private data
HWMON: dove: usemodule_platform_driverin dove hwmon driver
HWMON: dove: fix monitoring printks
hwmon is something that needs to be dealt with, but is nowhere near mainline ready.
Quoted 1 line
Quoted 1 line
Revert "Allow
ioremap_nocacheon PJ4 processor that is in Dove."
Not applicable to mainline; it's reverting a patch in Rabeeh's tree.
Quoted 1 line
Quoted 1 line
ARM: dove: convert legacy dove to PMU support
This one got dropped due to conflicts. It's now rebased on 4.3 (which is the earliest final kernel release it could be based upon, as the PMU code and conflicting changes were merged in the 4.3 merge window), I can finally think about resending it.
Quoted 1 line
Quoted 1 line
dt-bindings: add Marvell PMU documentation
Was sent in March and July, and obviously if it's still in my git tree, it never ended up being merged, and needs investigation as to what happened, and why it hasn't been merged along with the code.
Quoted 1 line
Quoted 1 line
of: Add vendor prefix for Vivante Corporation
Part of the etnaviv patch set.
So, out of all those matches, maybe one or two patches can be sent immediately. That still leaves me with about a hundred patches which are reliant on the non-DT dove code.
Signature · 2 lines
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
Quoted 8 lines · On Wednesday 25 November 2015 18:37:28 Russell King - ARM Linux wrote:
Quoted 3 lines · Andrew Lunn
Russell, you are the last known user of mach-dove. What are your plans? You keep saying you have given up trying to mainline your Cubox patches. Have you really given up? Can we remove mach-dove?
Right now, I'm developing etnaviv in spare time on the Cubox[*], which is still primarily running a non-DT kernel.
Quoted 10 lines
It's actually a kernel that I've hacked which is capable of booting both DT and non-DT, but even when booted in DT mode, I still require much of the
arch/arm/mach-doveinfrastructure to get things like armada-drm, etnaviv and other drivers running. Especially because we're missing things like the high-speed clocks (the stuff above the tclk domain.) I've not even started to work out how to get that into mainline, or how to integrate that with CCF. Quite what can be done with the audio patches, I've no idea, that remains a bone of contention and stalemate, and currently isn't DT-able. See the list of patches at the end of this message...
I think it's ok to keep mach-dove around for a longer time to keep the board file, I'm way more interested in completing the multiplatform work at last.
If I understand you right, being able to build mach-dove and mach-mvebu together will actually help you remove one or more of your patches, but of course will require a small bit of rebasing.
Arnd
Quoted 20 lines · Arnd Bergmann
Quoted 8 lines · On Wednesday 25 November 2015 18:37:28 Russell King - ARM Linux wrote:
Quoted 3 lines · Andrew Lunn
Russell, you are the last known user of mach-dove. What are your plans? You keep saying you have given up trying to mainline your Cubox patches. Have you really given up? Can we remove mach-dove?
Right now, I'm developing etnaviv in spare time on the Cubox[*], which is still primarily running a non-DT kernel.
Quoted 10 lines
It's actually a kernel that I've hacked which is capable of booting both DT and non-DT, but even when booted in DT mode, I still require much of the
arch/arm/mach-doveinfrastructure to get things like armada-drm, etnaviv and other drivers running. Especially because we're missing things like the high-speed clocks (the stuff above the tclk domain.) I've not even started to work out how to get that into mainline, or how to integrate that with CCF. Quite what can be done with the audio patches, I've no idea, that remains a bone of contention and stalemate, and currently isn't DT-able. See the list of patches at the end of this message...
Quoted 7 lines
I think it's ok to keep mach-dove around for a longer time to keep the board file, I'm way more interested in completing the multiplatform work at last.
If I understand you right, being able to build mach-dove and mach-mvebu together will actually help you remove one or more of your patches, but of course will require a small bit of rebasing.
This is something I already do, and it's trivial to make it work. You're doing it by moving some includes around, I've found that it's not necessary to move any includes around what so ever.
The problem I have right now is that people are expecting me to do everything at once: people want me to write documentation for the component helper. People want me to merge more Dove patches. People want me to merge the Armada 38x work I have queued. People are wanting to get the etnaviv kernel driver out for merging this week, now that I've solved the final part of the etnaviv puzzle - but yesterday I've uncovered another user API issue that needs to be discussed and resolved.
You know, there aren't enough me's to do everything - people just have to get used to the idea that if they're not willing to put the work in (iow, I have to put the work in) then things are going to be slow for anything that isn't funded work, because I have a lot on my plate.
In the case of Dove, I only ever look at the current state of things once every kernel cycle, as I only ever update the tree to a final kernel release. That means it takes about five months between submission and seeing the result of those patches merged, so I can then sort through what other stuff needs to be sent. Why six months? Get it queued for the next merge window (which can be up to six to eight weeks away). Then wait a full kernel cycle (eight to ten weeks) for it to appear in a final kernel. That's 14 to 18 weeks.
The last stuff which was merged was the PMU driver, merged in August. It's taken until 4.3 for this to become "visible" in my Dove tree. I should, at some point during this cycle - depending on my available time - start looking at what other pieces I can send, but what I'm saying is that this is the _earliest_ opportunity I have to start looking again at this.
Meanwhile, during this last merge window, more Armada DRM patches have gone in, along with some TDA998x patches - both of which I term Dove patches because that's their applicable kernel tree that they get tested with.
Meanwhile, Etnaviv is progressing, which again, is a Dove thing, because the Dove has a Vivante GC600 GPU, which etnaviv drives.
Meanwhile, Andrew's complaining that he's not seen anything from me for a long time. What Andrew can't see is that the work is going on at the peripheral driver level, not at the core level, /because/ it's the peripheral drivers which are blocking me dropping the non-DT support.
Signature · 2 lines
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
Quoted 10 lines · Arnd Bergmann
I've posted these before and now gotten around to a rebase and want to include them in the arm-soc next/multiplatform branch for 4.5.
Originally the plan for these platforms was to convert all of them to DT and use only mach-mvebu. That has not happened, so I would do it this way instead so we can at least have them in a single kernel.
Let me know if there are any concerns or objections.
Hi Arnd
I took a brief look at them.
Andrew
Hi Arnd,
Quoted 10 lines · Arnd Bergmann
I've posted these before and now gotten around to a rebase and want to include them in the arm-soc next/multiplatform branch for 4.5.
Originally the plan for these platforms was to convert all of them to DT and use only mach-mvebu. That has not happened, so I would do it this way instead so we can at least have them in a single kernel.
Let me know if there are any concerns or objections.
I have applied all the patches on mvebu/oldmvebu_multiplatform (I fixed the last one which didn't apply on Kconfig). I also merged it mvebu/for-netx to be part of the linux-next.
But before making it part of mvebu/soc, I would like to get some Tested-by. The series is available ongit://git.infradead.org/linux-mvebu.git
in the branch mvebu/oldmvebu_multiplatform but it also will be part soon of linux-next.
Russell, Sebastian,
would you have some time to test it on Dove?
Detlef, Benjamin,
could you test it on an Orion5x based board?
Evgeniy,
could you test it on an mv78xx0 base board?
Actually we consider removing the support for this SoC unless there are some user interested on them. As you are the last one claiming using a mainline kernel on a mv78xx0, keeping the support will mainly depends on you :)
Thanks,
Gregory
Quoted 104 lines
Arnd Bergmann (5):
ARM: orion: move watchdog setup to mach-orion5x
ARM: orion: always useMULTI_IRQ_HANDLER
ARM: orion: useSPARSE_IRQeverywhere
ARM: orion: clean up mach/*.h headers
ARM: orion: multiplatform supportarch/arm/Kconfig | 40 ------------------ arch/arm/configs/dove_defconfig | 2 + arch/arm/configs/mv78xx0_defconfig | 3 ++ arch/arm/configs/orion5x_defconfig | 3 ++ arch/arm/mach-dove/Kconfig | 15 +++++-- arch/arm/mach-dove/Makefile | 2 + .../arm/mach-dove/{include/mach => }/bridge-regs.h | 4 +- arch/arm/mach-dove/cm-a510.c | 4 +- arch/arm/mach-dove/common.c | 4 +- arch/arm/mach-dove/dove-db-setup.c | 3 +- arch/arm/mach-dove/{include/mach => }/dove.h | 4 +- arch/arm/mach-dove/include/mach/entry-macro.S | 33 --------------- arch/arm/mach-dove/include/mach/hardware.h | 19 --------- arch/arm/mach-dove/include/mach/uncompress.h | 36 ---------------- arch/arm/mach-dove/irq.c | 22 ++++------ arch/arm/mach-dove/{include/mach => }/irqs.h | 4 +- arch/arm/mach-dove/mpp.c | 2 +- arch/arm/mach-dove/pcie.c | 4 +- arch/arm/mach-dove/{include/mach => }/pm.h | 6 +-- arch/arm/mach-mv78xx0/Kconfig | 15 +++++-- arch/arm/mach-mv78xx0/Makefile | 2 + .../mach-mv78xx0/{include/mach => }/bridge-regs.h | 4 +- arch/arm/mach-mv78xx0/buffalo-wxl-setup.c | 3 +- arch/arm/mach-mv78xx0/common.c | 4 +- arch/arm/mach-mv78xx0/db78x00-bp-setup.c | 3 +- arch/arm/mach-mv78xx0/include/mach/entry-macro.S | 41 ------------------ arch/arm/mach-mv78xx0/include/mach/hardware.h | 14 ------- arch/arm/mach-mv78xx0/include/mach/uncompress.h | 46 --------------------- arch/arm/mach-mv78xx0/irq.c | 35 +++++++++++++++- arch/arm/mach-mv78xx0/{include/mach => }/irqs.h | 4 +- arch/arm/mach-mv78xx0/mpp.c | 2 +- arch/arm/mach-mv78xx0/{include/mach => }/mv78xx0.h | 4 +- arch/arm/mach-mv78xx0/pcie.c | 2 +- arch/arm/mach-mv78xx0/rd78x00-masa-setup.c | 3 +- arch/arm/mach-orion5x/Kconfig | 18 ++++++-- arch/arm/mach-orion5x/Makefile | 2 + arch/arm/mach-orion5x/board-d2net.c | 2 +- arch/arm/mach-orion5x/board-dt.c | 4 +- arch/arm/mach-orion5x/board-mss2.c | 4 +- arch/arm/mach-orion5x/board-rd88f5182.c | 2 +- .../mach-orion5x/{include/mach => }/bridge-regs.h | 4 +- arch/arm/mach-orion5x/common.c | 20 +++++++-- arch/arm/mach-orion5x/db88f5281-setup.c | 3 +- arch/arm/mach-orion5x/dns323-setup.c | 3 +- arch/arm/mach-orion5x/include/mach/entry-macro.S | 25 ----------- arch/arm/mach-orion5x/include/mach/hardware.h | 14 ------- arch/arm/mach-orion5x/include/mach/uncompress.h | 48 ---------------------- arch/arm/mach-orion5x/irq.c | 13 +----- arch/arm/mach-orion5x/{include/mach => }/irqs.h | 4 +- arch/arm/mach-orion5x/kurobox_pro-setup.c | 4 +- arch/arm/mach-orion5x/ls-chl-setup.c | 3 +- arch/arm/mach-orion5x/ls_hgl-setup.c | 3 +- arch/arm/mach-orion5x/mpp.c | 2 +- arch/arm/mach-orion5x/mv2120-setup.c | 3 +- arch/arm/mach-orion5x/net2big-setup.c | 3 +- arch/arm/mach-orion5x/{include/mach => }/orion5x.h | 4 +- arch/arm/mach-orion5x/pci.c | 2 +- arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c | 3 +- arch/arm/mach-orion5x/rd88f5181l-ge-setup.c | 3 +- arch/arm/mach-orion5x/rd88f5182-setup.c | 3 +- arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c | 3 +- arch/arm/mach-orion5x/terastation_pro2-setup.c | 3 +- arch/arm/mach-orion5x/ts209-setup.c | 3 +- arch/arm/mach-orion5x/ts409-setup.c | 3 +- arch/arm/mach-orion5x/ts78xx-setup.c | 3 +- arch/arm/mach-orion5x/tsx09-common.c | 2 +- arch/arm/mach-orion5x/wnr854t-setup.c | 3 +- arch/arm/mach-orion5x/wrt350n-v2-setup.c | 3 +- arch/arm/plat-orion/common.c | 21 ---------- arch/arm/plat-orion/include/plat/common.h | 2 - arch/arm/plat-orion/irq.c | 1 - arch/arm/plat-orion/mpp.c | 1 - 72 files changed, 185 insertions(+), 454 deletions(-) rename arch/arm/mach-dove/{include/mach => }/bridge-regs.h (96%) rename arch/arm/mach-dove/{include/mach => }/dove.h (99%) delete mode 100644 arch/arm/mach-dove/include/mach/entry-macro.S delete mode 100644 arch/arm/mach-dove/include/mach/hardware.h delete mode 100644 arch/arm/mach-dove/include/mach/uncompress.h rename arch/arm/mach-dove/{include/mach => }/irqs.h (96%) rename arch/arm/mach-dove/{include/mach => }/pm.h (95%) rename arch/arm/mach-mv78xx0/{include/mach => }/bridge-regs.h (92%) delete mode 100644 arch/arm/mach-mv78xx0/include/mach/entry-macro.S delete mode 100644 arch/arm/mach-mv78xx0/include/mach/hardware.h delete mode 100644 arch/arm/mach-mv78xx0/include/mach/uncompress.h rename arch/arm/mach-mv78xx0/{include/mach => }/irqs.h (95%) rename arch/arm/mach-mv78xx0/{include/mach => }/mv78xx0.h (98%) rename arch/arm/mach-orion5x/{include/mach => }/bridge-regs.h (92%) delete mode 100644 arch/arm/mach-orion5x/include/mach/entry-macro.S delete mode 100644 arch/arm/mach-orion5x/include/mach/hardware.h delete mode 100644 arch/arm/mach-orion5x/include/mach/uncompress.h rename arch/arm/mach-orion5x/{include/mach => }/irqs.h (94%) rename arch/arm/mach-orion5x/{include/mach => }/orion5x.h (99%)Signature · 1 line
2.1.0.rc2
Signature · 4 lines
Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
cover ARM: orion5x/dove/mv78xx0 multiplatform
Quoted 27 lines · Gregory CLEMENT
Hi Arnd,
Quoted 10 lines · Arnd Bergmann
I've posted these before and now gotten around to a rebase and want to include them in the arm-soc next/multiplatform branch for 4.5.
Originally the plan for these platforms was to convert all of them to DT and use only mach-mvebu. That has not happened, so I would do it this way instead so we can at least have them in a single kernel.
Let me know if there are any concerns or objections.
I have applied all the patches on mvebu/oldmvebu_multiplatform (I fixed the last one which didn't apply on
Kconfig). I also merged it mvebu/for-netx to be part of the linux-next.But before making it part of mvebu/soc, I would like to get some Tested-by. The series is available on
git://git.infradead.org/linux-mvebu.git
in the branch mvebu/oldmvebu_multiplatform but it also will be part soon of linux-next.Russell, Sebastian,
Quoted 7 lines
would you have some time to test it on Dove?
Detlef, Benjamin,
could you test it on an Orion5x based board?
Evgeniy,
I forgot to add to add Evgeniy's email adress. It is fixed now.
Quoted 127 lines
could you test it on an mv78xx0 base board?
Actually we consider removing the support for this SoC unless there are some user interested on them. As you are the last one claiming using a mainline kernel on a mv78xx0, keeping the support will mainly depends on you :)
Thanks,
Gregory
Quoted 104 lines
Arnd Bergmann (5):
ARM: orion: move watchdog setup to mach-orion5x
ARM: orion: always useMULTI_IRQ_HANDLER
ARM: orion: useSPARSE_IRQeverywhere
ARM: orion: clean up mach/*.h headers
ARM: orion: multiplatform supportarch/arm/Kconfig | 40 ------------------ arch/arm/configs/dove_defconfig | 2 + arch/arm/configs/mv78xx0_defconfig | 3 ++ arch/arm/configs/orion5x_defconfig | 3 ++ arch/arm/mach-dove/Kconfig | 15 +++++-- arch/arm/mach-dove/Makefile | 2 + .../arm/mach-dove/{include/mach => }/bridge-regs.h | 4 +- arch/arm/mach-dove/cm-a510.c | 4 +- arch/arm/mach-dove/common.c | 4 +- arch/arm/mach-dove/dove-db-setup.c | 3 +- arch/arm/mach-dove/{include/mach => }/dove.h | 4 +- arch/arm/mach-dove/include/mach/entry-macro.S | 33 --------------- arch/arm/mach-dove/include/mach/hardware.h | 19 --------- arch/arm/mach-dove/include/mach/uncompress.h | 36 ---------------- arch/arm/mach-dove/irq.c | 22 ++++------ arch/arm/mach-dove/{include/mach => }/irqs.h | 4 +- arch/arm/mach-dove/mpp.c | 2 +- arch/arm/mach-dove/pcie.c | 4 +- arch/arm/mach-dove/{include/mach => }/pm.h | 6 +-- arch/arm/mach-mv78xx0/Kconfig | 15 +++++-- arch/arm/mach-mv78xx0/Makefile | 2 + .../mach-mv78xx0/{include/mach => }/bridge-regs.h | 4 +- arch/arm/mach-mv78xx0/buffalo-wxl-setup.c | 3 +- arch/arm/mach-mv78xx0/common.c | 4 +- arch/arm/mach-mv78xx0/db78x00-bp-setup.c | 3 +- arch/arm/mach-mv78xx0/include/mach/entry-macro.S | 41 ------------------ arch/arm/mach-mv78xx0/include/mach/hardware.h | 14 ------- arch/arm/mach-mv78xx0/include/mach/uncompress.h | 46 --------------------- arch/arm/mach-mv78xx0/irq.c | 35 +++++++++++++++- arch/arm/mach-mv78xx0/{include/mach => }/irqs.h | 4 +- arch/arm/mach-mv78xx0/mpp.c | 2 +- arch/arm/mach-mv78xx0/{include/mach => }/mv78xx0.h | 4 +- arch/arm/mach-mv78xx0/pcie.c | 2 +- arch/arm/mach-mv78xx0/rd78x00-masa-setup.c | 3 +- arch/arm/mach-orion5x/Kconfig | 18 ++++++-- arch/arm/mach-orion5x/Makefile | 2 + arch/arm/mach-orion5x/board-d2net.c | 2 +- arch/arm/mach-orion5x/board-dt.c | 4 +- arch/arm/mach-orion5x/board-mss2.c | 4 +- arch/arm/mach-orion5x/board-rd88f5182.c | 2 +- .../mach-orion5x/{include/mach => }/bridge-regs.h | 4 +- arch/arm/mach-orion5x/common.c | 20 +++++++-- arch/arm/mach-orion5x/db88f5281-setup.c | 3 +- arch/arm/mach-orion5x/dns323-setup.c | 3 +- arch/arm/mach-orion5x/include/mach/entry-macro.S | 25 ----------- arch/arm/mach-orion5x/include/mach/hardware.h | 14 ------- arch/arm/mach-orion5x/include/mach/uncompress.h | 48 ---------------------- arch/arm/mach-orion5x/irq.c | 13 +----- arch/arm/mach-orion5x/{include/mach => }/irqs.h | 4 +- arch/arm/mach-orion5x/kurobox_pro-setup.c | 4 +- arch/arm/mach-orion5x/ls-chl-setup.c | 3 +- arch/arm/mach-orion5x/ls_hgl-setup.c | 3 +- arch/arm/mach-orion5x/mpp.c | 2 +- arch/arm/mach-orion5x/mv2120-setup.c | 3 +- arch/arm/mach-orion5x/net2big-setup.c | 3 +- arch/arm/mach-orion5x/{include/mach => }/orion5x.h | 4 +- arch/arm/mach-orion5x/pci.c | 2 +- arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c | 3 +- arch/arm/mach-orion5x/rd88f5181l-ge-setup.c | 3 +- arch/arm/mach-orion5x/rd88f5182-setup.c | 3 +- arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c | 3 +- arch/arm/mach-orion5x/terastation_pro2-setup.c | 3 +- arch/arm/mach-orion5x/ts209-setup.c | 3 +- arch/arm/mach-orion5x/ts409-setup.c | 3 +- arch/arm/mach-orion5x/ts78xx-setup.c | 3 +- arch/arm/mach-orion5x/tsx09-common.c | 2 +- arch/arm/mach-orion5x/wnr854t-setup.c | 3 +- arch/arm/mach-orion5x/wrt350n-v2-setup.c | 3 +- arch/arm/plat-orion/common.c | 21 ---------- arch/arm/plat-orion/include/plat/common.h | 2 - arch/arm/plat-orion/irq.c | 1 - arch/arm/plat-orion/mpp.c | 1 - 72 files changed, 185 insertions(+), 454 deletions(-) rename arch/arm/mach-dove/{include/mach => }/bridge-regs.h (96%) rename arch/arm/mach-dove/{include/mach => }/dove.h (99%) delete mode 100644 arch/arm/mach-dove/include/mach/entry-macro.S delete mode 100644 arch/arm/mach-dove/include/mach/hardware.h delete mode 100644 arch/arm/mach-dove/include/mach/uncompress.h rename arch/arm/mach-dove/{include/mach => }/irqs.h (96%) rename arch/arm/mach-dove/{include/mach => }/pm.h (95%) rename arch/arm/mach-mv78xx0/{include/mach => }/bridge-regs.h (92%) delete mode 100644 arch/arm/mach-mv78xx0/include/mach/entry-macro.S delete mode 100644 arch/arm/mach-mv78xx0/include/mach/hardware.h delete mode 100644 arch/arm/mach-mv78xx0/include/mach/uncompress.h rename arch/arm/mach-mv78xx0/{include/mach => }/irqs.h (95%) rename arch/arm/mach-mv78xx0/{include/mach => }/mv78xx0.h (98%) rename arch/arm/mach-orion5x/{include/mach => }/bridge-regs.h (92%) delete mode 100644 arch/arm/mach-orion5x/include/mach/entry-macro.S delete mode 100644 arch/arm/mach-orion5x/include/mach/hardware.h delete mode 100644 arch/arm/mach-orion5x/include/mach/uncompress.h rename arch/arm/mach-orion5x/{include/mach => }/irqs.h (94%) rename arch/arm/mach-orion5x/{include/mach => }/orion5x.h (99%)Signature · 1 line
2.1.0.rc2Signature · 9 lines
Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel at lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Signature · 4 lines
Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
cover ARM: orion5x/dove/mv78xx0 multiplatform
On Mon, 30 Nov 2015 14:43:56 +0100
Gregory CLEMENT <[email protected]> wrote:
[...]
Quoted 3 lines
Quoted 3 lines
Detlef, Benjamin,
could you test it on an Orion5x based board?
Sorry, I'm on tour right now.
I'll test it next weekend (or beginning next week) on my DNS-323.
Detlef
cover ARM: orion5x/dove/mv78xx0 multiplatform
Hi Detlef,
Quoted 8 lines · Detlef Vollmann
On Mon, 30 Nov 2015 14:43:56 +0100
Gregory CLEMENT <[email protected]> wrote:
[...]Quoted 3 lines
Quoted 3 lines
Detlef, Benjamin,
could you test it on an Orion5x based board?
Sorry, I'm on tour right now.
I'll test it next weekend (or beginning next week) on my DNS-323.
We have still some time to send the series, and furthermore Andrew already tested it on an Orion5x platform. However it would be nice to have your confirmation on an other board.
Thanks,
Gregory
Signature · 4 lines
Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
Andrew Lunn
maintainerQuoted 9 lines · Gregory CLEMENT
Hi Detlef,
Quoted 5 lines · Detlef Vollmann
On Mon, 30 Nov 2015 14:43:56 +0100
Gregory CLEMENT <[email protected]> wrote:
[...]Quoted 2 lines
Quoted 2 lines
Detlef, Benjamin,
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line
could you test it on an Orion5x based board?
Sorry, I'm on tour right now.
I'll test it next weekend (or beginning next week) on my DNS-323.We have still some time to send the series, and furthermore Andrew already tested it on an Orion5x platform. However it would be nice to have your confirmation on an other board.
Hi Gregory
To help with testing, could you pull the defconfig changes into the branch? I cannot boot the multi_v5_defconfig on my Orion5x. Its CPU is too old, and needs CONFIG_CPU_FEROCEON_OLD_ID, but that is not available because CPU_ARM926T is enabled.
Thanks
Andrew
cover ARM: orion5x/dove/mv78xx0 multiplatform
In reply to Gregory CLEMENTQuoted 3 lines · Gregory CLEMENT
Quoted 3 lines
Detlef, Benjamin,
could you test it on an Orion5x based board?
Ok, I tested the v2 series on v4.4-rc3 on my
DNS-323: Identified HW revision B1
Orion ID: MV88F5182-A2. TCLK=166666667.
Only basic tests, serial port and network.
The good news:orion5x_defconfig works and is even slightly smaller than the original v4.4-rc3 kernel image.
The bad news:
My own config (which is massivly stripped down) produces a kernel image that's more than 26K bigger than on v4.4-rc3 without any added functionality.
The DNS-323 is extremly constrained in space (the whole system including boot loader, kernel and filesystem has to fit into 8M flash). Any ideas how I can get rid of this additional overhead?
Detlef
Quoted 14 lines · On Thursday 10 December 2015 13:56:05 Detlef Vollmann wrote:
Quoted 3 lines · Gregory CLEMENT
Quoted 3 lines
Detlef, Benjamin,
could you test it on an Orion5x based board?
Ok, I tested the v2 series on v4.4-rc3 on my
DNS-323: Identified HW revision B1
Orion ID: MV88F5182-A2. TCLK=166666667.Only basic tests, serial port and network.
The good news:
orion5x_defconfigworks and is even slightly smaller than the original v4.4-rc3 kernel image.
Quoted 7 lines
The bad news:
My own config (which is massivly stripped down) produces a kernel image that's more than 26K bigger than on v4.4-rc3 without any added functionality.
The DNS-323 is extremly constrained in space (the whole system including boot loader, kernel and filesystem has to fit into 8M flash). Any ideas how I can get rid of this additional overhead?
Can you send me your config file? I can have a look.
Arnd
Quoted 23 lines · On Thursday 10 December 2015 14:18:11 Arnd Bergmann wrote:
Quoted 14 lines · On Thursday 10 December 2015 13:56:05 Detlef Vollmann wrote:
Quoted 3 lines · Gregory CLEMENT
Quoted 3 lines
Detlef, Benjamin,
could you test it on an Orion5x based board?
Ok, I tested the v2 series on v4.4-rc3 on my
DNS-323: Identified HW revision B1
Orion ID: MV88F5182-A2. TCLK=166666667.Only basic tests, serial port and network.
The good news:
orion5x_defconfigworks and is even slightly smaller than the original v4.4-rc3 kernel image.Quoted 7 lines
The bad news:
My own config (which is massivly stripped down) produces a kernel image that's more than 26K bigger than on v4.4-rc3 without any added functionality.
The DNS-323 is extremly constrained in space (the whole system including boot loader, kernel and filesystem has to fit into 8M flash). Any ideas how I can get rid of this additional overhead?
Quoted 2 lines
Can you send me your config file? I can have a look.
I've done a quick check with an allnoconfig-like test and it seems that CONFIG_OF is weighing in at around 86K here, with all the other options it pulls in, comparing an allnoconfig kernel for DS-323 with one that has CONFIG_OF enabled as well.
The multiplatform kernel also enables CONFIG_OF unconditionally, but is otherwise a little smaller than the mach-orion5x based one:
text data bss dec hex filename
942144 64112 17648 1023904 f9fa0 build/tmp/vmlinux-orion-allno 1027516 54052 20824 1102392 10d238 build/tmp/vmlinux-multi-plus-orion 1025320 66020 18744 1110084 10f044 build/tmp/vmlinux-orion-plus-of
The diff below shows all the differences between orion-allno and multi-plus-orion.
Arnd
.config renamed from config-orion +79 -14
@@ -3,6 +3,8 @@ # Linux/arm 4.4.0-rc4 Kernel Configuration # CONFIG_ARM=y +CONFIG_ARM_HAS_SG_CHAIN=y +CONFIG_MIGHT_HAVE_PCI=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y
@@ -14,8 +16,7 @@ CONFIG_NEED_DMA_MAP_STATE=y CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_VECTORS_BASE=0xffff0000 -# CONFIG_ARM_PATCH_PHYS_VIRT is not set -CONFIG_PHYS_OFFSET=0x0 +CONFIG_ARM_PATCH_PHYS_VIRT=y CONFIG_PGTABLE_LEVELS=2 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_BUILDTIME_EXTABLE_SORT=y
@@ -56,6 +57,7 @@ CONFIG_IRQ_DOMAIN=y CONFIG_HANDLE_DOMAIN_IRQ=y CONFIG_IRQ_FORCED_THREADING=y +CONFIG_SPARSE_IRQ=y CONFIG_GENERIC_CLOCKEVENTS=y #
@@ -186,7 +188,7 @@ # System Type # CONFIG_MMU=y -# CONFIG_ARCH_MULTIPLATFORM is not set +CONFIG_ARCH_MULTIPLATFORM=y # CONFIG_ARCH_VERSATILE is not set # CONFIG_ARCH_CLPS711X is not set # CONFIG_ARCH_GEMINI is not set
@@ -198,9 +200,6 @@ # CONFIG_ARCH_IOP32X is not set # CONFIG_ARCH_IOP33X is not set # CONFIG_ARCH_IXP4XX is not set -# CONFIG_ARCH_DOVE is not set -# CONFIG_ARCH_MV78XX0 is not set -CONFIG_ARCH_ORION5X=y # CONFIG_ARCH_KS8695 is not set # CONFIG_ARCH_W90X900 is not set # CONFIG_ARCH_LPC32XX is not set
@@ -212,8 +211,29 @@ # CONFIG_ARCH_OMAP1 is not set # -# Orion Implementations +# Multiple platform selection +# + # +# CPU Core family selection +# +# CONFIG_ARCH_MULTI_V4 is not set +# CONFIG_ARCH_MULTI_V4T is not set +CONFIG_ARCH_MULTI_V5=y +CONFIG_ARCH_MULTI_V4_V5=y +# CONFIG_ARCH_MULTI_V6 is not set +# CONFIG_ARCH_MULTI_V7 is not set +CONFIG_ARCH_MULTI_CPU_AUTO=y +# CONFIG_ARCH_MVEBU is not set +# CONFIG_MACH_ASM9260 is not set +# CONFIG_ARCH_AT91 is not set +# CONFIG_ARCH_INTEGRATOR is not set +# CONFIG_ARCH_MV78XX0 is not set +# CONFIG_ARCH_MXC is not set +# CONFIG_ARCH_MXS is not set +# CONFIG_ARCH_NOMADIK is not set +# CONFIG_ARCH_NSPIRE is not set +CONFIG_ARCH_ORION5X=y # CONFIG_ARCH_ORION5X_DT is not set # CONFIG_MACH_DB88F5281 is not set # CONFIG_MACH_RD88F5182 is not set
@@ -237,6 +257,11 @@ # CONFIG_MACH_RD88F5181L_GE is not set # CONFIG_MACH_RD88F5181L_FXO is not set # CONFIG_MACH_RD88F6183AP_GE is not set +# CONFIG_ARCH_MMP is not set +# CONFIG_ARCH_REALVIEW is not set +# CONFIG_PLAT_SPEAR is not set +# CONFIG_ARCH_U300 is not set +# CONFIG_ARCH_WM8505 is not set CONFIG_PLAT_ORION=y CONFIG_PLAT_ORION_LEGACY=y
@@ -286,6 +311,10 @@ # # PCI host controller drivers # +# CONFIG_PCI_HOST_GENERIC is not set +# CONFIG_PCI_LAYERSCAPE is not set +# CONFIG_PCIE_IPROC is not set +# CONFIG_PCIE_ALTERA is not set # CONFIG_PCIEPORTBUS is not set # CONFIG_PCCARD is not set
@@ -346,16 +375,16 @@ # # Boot options # -# CONFIG_USE_OF is not set +CONFIG_USE_OF=y CONFIG_ATAGS=y # CONFIG_DEPRECATED_PARAM_STRUCT is not set CONFIG_ZBOOT_ROM_TEXT=0 CONFIG_ZBOOT_ROM_BSS=0 +# CONFIG_ARM_APPENDED_DTB is not set CONFIG_CMDLINE="" -# CONFIG_XIP_KERNEL is not set # CONFIG_KEXEC is not set # CONFIG_CRASH_DUMP is not set -# CONFIG_AUTO_ZRELADDR is not set +CONFIG_AUTO_ZRELADDR=y # # CPU Power Management
@@ -427,8 +456,20 @@ # # CONFIG_BRCMSTB_GISB_ARB is not set CONFIG_MVEBU_MBUS=y +# CONFIG_VEXPRESS_CONFIG is not set # CONFIG_MTD is not set -# CONFIG_OF is not set +CONFIG_DTC=y +CONFIG_OF=y +# CONFIG_OF_UNITTEST is not set +CONFIG_OF_FLATTREE=y +CONFIG_OF_EARLY_FLATTREE=y +CONFIG_OF_ADDRESS=y +CONFIG_OF_ADDRESS_PCI=y +CONFIG_OF_IRQ=y +CONFIG_OF_PCI=y +CONFIG_OF_PCI_IRQ=y +CONFIG_OF_RESERVED_MEM=y +# CONFIG_OF_OVERLAY is not set CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y # CONFIG_PARPORT is not set
@@ -550,17 +591,26 @@ # Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks. # CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y +CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y CONFIG_ARCH_REQUIRE_GPIOLIB=y CONFIG_GPIOLIB=y CONFIG_GPIO_DEVRES=y +CONFIG_OF_GPIO=y # CONFIG_DEBUG_GPIO is not set # # Memory mapped GPIO drivers # +# CONFIG_GPIO_74XX_MMIO is not set +# CONFIG_GPIO_ALTERA is not set # CONFIG_GPIO_DWAPB is not set +# CONFIG_GPIO_EM is not set # CONFIG_GPIO_GENERIC_PLATFORM is not set +# CONFIG_GPIO_GRGPIO is not set +CONFIG_GPIO_MVEBU=y # CONFIG_GPIO_VX855 is not set +# CONFIG_GPIO_XILINX is not set +# CONFIG_GPIO_ZEVIO is not set # CONFIG_GPIO_ZX is not set #
@@ -597,8 +647,11 @@ # Multifunction device drivers # # CONFIG_MFD_CORE is not set +# CONFIG_MFD_ATMEL_FLEXCOM is not set +# CONFIG_MFD_ATMEL_HLCDC is not set # CONFIG_MFD_CROS_EC is not set # CONFIG_MFD_ASIC3 is not set +# CONFIG_MFD_HI6421_PMIC is not set # CONFIG_HTC_EGPIO is not set # CONFIG_HTC_PASIC3 is not set # CONFIG_LPC_ICH is not set
@@ -670,6 +723,7 @@ # # Common Clock Framework # +# CONFIG_CLK_QORIQ is not set # CONFIG_COMMON_CLK_PXA is not set #
@@ -679,6 +733,8 @@ # # Clock Source drivers # +CONFIG_CLKSRC_OF=y +CONFIG_CLKSRC_PROBE=y CONFIG_CLKSRC_MMIO=y # CONFIG_ARM_TIMER_SP804 is not set # CONFIG_ATMEL_PIT is not set
@@ -711,6 +767,7 @@ # CONFIG_NTB is not set # CONFIG_VME_BUS is not set # CONFIG_PWM is not set +CONFIG_IRQCHIP=y # CONFIG_IPACK_BUS is not set # CONFIG_RESET_CONTROLLER is not set # CONFIG_FMC is not set
@@ -907,7 +964,7 @@ CONFIG_DEBUG_UART_8250_SHIFT=2 # CONFIG_DEBUG_UART_8250_WORD is not set # CONFIG_DEBUG_UART_8250_FLOW_CONTROL is not set -CONFIG_UNCOMPRESS_INCLUDE="mach/uncompress.h" +CONFIG_UNCOMPRESS_INCLUDE="debug/uncompress.h" # CONFIG_CORESIGHT is not set #
@@ -924,6 +981,8 @@ # # Library routines # +CONFIG_BITREVERSE=y +# CONFIG_HAVE_ARCH_BITREVERSE is not set CONFIG_RATIONAL=y CONFIG_GENERIC_STRNCPY_FROM_USER=y CONFIG_GENERIC_STRNLEN_USER=y
@@ -935,7 +994,12 @@ # CONFIG_CRC16 is not set # CONFIG_CRC_T10DIF is not set # CONFIG_CRC_ITU_T is not set -# CONFIG_CRC32 is not set +CONFIG_CRC32=y +# CONFIG_CRC32_SELFTEST is not set +CONFIG_CRC32_SLICEBY8=y +# CONFIG_CRC32_SLICEBY4 is not set +# CONFIG_CRC32_SARWATE is not set +# CONFIG_CRC32_BIT is not set # CONFIG_CRC7 is not set # CONFIG_LIBCRC32C is not set # CONFIG_CRC8 is not set
@@ -952,6 +1016,7 @@ CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y # CONFIG_CORDIC is not set # CONFIG_DDR is not set +CONFIG_LIBFDT=y # CONFIG_SG_SPLIT is not set -# CONFIG_ARCH_HAS_SG_CHAIN is not set +CONFIG_ARCH_HAS_SG_CHAIN=y # CONFIG_VIRTUALIZATION is not set
cover ARM: orion5x/dove/mv78xx0 multiplatform
Quoted 22 lines · Arnd Bergmann
Quoted 10 lines · On Thursday 10 December 2015 14:18:11 Arnd Bergmann wrote:
Quoted 7 lines · On Thursday 10 December 2015 13:56:05 Detlef Vollmann wrote:
The bad news:
My own config (which is massivly stripped down) produces a kernel image that's more than 26K bigger than on v4.4-rc3 without any added functionality.
The DNS-323 is extremly constrained in space (the whole system including boot loader, kernel and filesystem has to fit into 8M flash). Any ideas how I can get rid of this additional overhead?Quoted 2 lines
Can you send me your config file? I can have a look.
I've done a quick check with an allnoconfig-like test and it seems that
CONFIG_OFis weighing in at around 86K here, with all the other options it pulls in, comparing an allnoconfig kernel for DS-323 with one that hasCONFIG_OFenabled as well.The multiplatform kernel also enables
CONFIG_OFunconditionally, but is otherwise a little smaller than the mach-orion5x based one:
Quoted 7 lines
text data bss dec hex filename
942144 64112 17648 1023904 f9fa0 build/tmp/vmlinux-orion-allno 1027516 54052 20824 1102392 10d238 build/tmp/vmlinux-multi-plus-orion 1025320 66020 18744 1110084 10f044 build/tmp/vmlinux-orion-plus-ofThe diff below shows all the differences between orion-allno and multi-plus-orion.
How did you get the orion-allno config and how did you get it compiled? I tried to apply your changes to my config and compile it, but it started silentoldconfig which introduced back 'ARCH_MULTIPLATFORM'
Detlef
Quoted 28 lines · On Thursday 10 December 2015 20:03:18 Detlef Vollmann wrote:
Quoted 27 lines · Arnd Bergmann
Quoted 10 lines · On Thursday 10 December 2015 14:18:11 Arnd Bergmann wrote:
Quoted 7 lines · On Thursday 10 December 2015 13:56:05 Detlef Vollmann wrote:
The bad news:
My own config (which is massivly stripped down) produces a kernel image that's more than 26K bigger than on v4.4-rc3 without any added functionality.
The DNS-323 is extremly constrained in space (the whole system including boot loader, kernel and filesystem has to fit into 8M flash). Any ideas how I can get rid of this additional overhead?Quoted 2 lines
Can you send me your config file? I can have a look.
I've done a quick check with an allnoconfig-like test and it seems that
CONFIG_OFis weighing in at around 86K here, with all the other options it pulls in, comparing an allnoconfig kernel for DS-323 with one that hasCONFIG_OFenabled as well.The multiplatform kernel also enables
CONFIG_OFunconditionally, but is otherwise a little smaller than the mach-orion5x based one:text data bss dec hex filename
942144 64112 17648 1023904 f9fa0 build/tmp/vmlinux-orion-allno 1027516 54052 20824 1102392 10d238 build/tmp/vmlinux-multi-plus-orion 1025320 66020 18744 1110084 10f044 build/tmp/vmlinux-orion-plus-of
Quoted 5 lines
Quoted 2 lines
The diff below shows all the differences between orion-allno and multi-plus-orion.
How did you get the orion-allno config and how did you get it compiled? I tried to apply your changes to my config and compile it, but it started silentoldconfig which introduced back '
ARCH_MULTIPLATFORM'
The first and third row are without my patches, once they are applied, ARCH_ORION becomes a sub-option of ARCH_MULTIPLATFORM.
Arnd
cover ARM: orion5x/dove/mv78xx0 multiplatform
Quoted 29 lines · Arnd Bergmann
Quoted 28 lines · On Thursday 10 December 2015 20:03:18 Detlef Vollmann wrote:
Quoted 27 lines · Arnd Bergmann
Quoted 10 lines · On Thursday 10 December 2015 14:18:11 Arnd Bergmann wrote:
Quoted 7 lines · On Thursday 10 December 2015 13:56:05 Detlef Vollmann wrote:
The bad news:
My own config (which is massivly stripped down) produces a kernel image that's more than 26K bigger than on v4.4-rc3 without any added functionality.
The DNS-323 is extremly constrained in space (the whole system including boot loader, kernel and filesystem has to fit into 8M flash). Any ideas how I can get rid of this additional overhead?Quoted 2 lines
Can you send me your config file? I can have a look.
I've done a quick check with an allnoconfig-like test and it seems that
CONFIG_OFis weighing in at around 86K here, with all the other options it pulls in, comparing an allnoconfig kernel for DS-323 with one that hasCONFIG_OFenabled as well.The multiplatform kernel also enables
CONFIG_OFunconditionally, but is otherwise a little smaller than the mach-orion5x based one:text data bss dec hex filename
942144 64112 17648 1023904 f9fa0 build/tmp/vmlinux-orion-allno 1027516 54052 20824 1102392 10d238 build/tmp/vmlinux-multi-plus-orion 1025320 66020 18744 1110084 10f044 build/tmp/vmlinux-orion-plus-of
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
The diff below shows all the differences between orion-allno and multi-plus-orion.
How did you get the orion-allno config and how did you get it compiled? I tried to apply your changes to my config and compile it, but it started silentoldconfig which introduced back '
ARCH_MULTIPLATFORM'The first and third row are without my patches, once they are applied,
ARCH_ORIONbecomes a sub-option ofARCH_MULTIPLATFORM.
So with your patches it's no longer possible to build a small kernel, correct?
Detlef
Quoted 10 lines · On Thursday 10 December 2015 22:14:25 Detlef Vollmann wrote:
Quoted 9 lines · Arnd Bergmann
Quoted 8 lines · On Thursday 10 December 2015 20:03:18 Detlef Vollmann wrote:
Quoted 7 lines · Arnd Bergmann
text data bss dec hex filename
942144 64112 17648 1023904 f9fa0 build/tmp/vmlinux-orion-allno 1027516 54052 20824 1102392 10d238 build/tmp/vmlinux-multi-plus-orion 1025320 66020 18744 1110084 10f044 build/tmp/vmlinux-orion-plus-ofThe diff below shows all the differences between orion-allno and multi-plus-orion.
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
How did you get the orion-allno config and how did you get it compiled? I tried to apply your changes to my config and compile it, but it started silentoldconfig which introduced back '
ARCH_MULTIPLATFORM'The first and third row are without my patches, once they are applied,
ARCH_ORIONbecomes a sub-option ofARCH_MULTIPLATFORM.So with your patches it's no longer possible to build a small kernel, correct?
Correct. I was a bit surprised at how much object code enabling CONFIG_OF adds these days, it used to be a lot less, but you are right that disabling CONFIG_OF is not possible with the way that ARCH_MULTIPLATFORM is structured.
It was always the plan to move all orion5x machines over to use CONFIG_OF eventually, so you get that overhead one way or another, and at least it looks like doing multiplatform on top of OF doesn't add any noticeable extra overhead (the total numbers are actually smaller).
It may also be worth investigating what has made CONFIG_OF so costly, maybe we can reduce this a bit again.
Arnd
cover ARM: orion5x/dove/mv78xx0 multiplatform
Quoted 25 lines · Arnd Bergmann
Quoted 10 lines · On Thursday 10 December 2015 22:14:25 Detlef Vollmann wrote:
Quoted 9 lines · Arnd Bergmann
Quoted 8 lines · On Thursday 10 December 2015 20:03:18 Detlef Vollmann wrote:
Quoted 7 lines · Arnd Bergmann
text data bss dec hex filename
942144 64112 17648 1023904 f9fa0 build/tmp/vmlinux-orion-allno 1027516 54052 20824 1102392 10d238 build/tmp/vmlinux-multi-plus-orion 1025320 66020 18744 1110084 10f044 build/tmp/vmlinux-orion-plus-ofThe diff below shows all the differences between orion-allno and multi-plus-orion.
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
How did you get the orion-allno config and how did you get it compiled? I tried to apply your changes to my config and compile it, but it started silentoldconfig which introduced back '
ARCH_MULTIPLATFORM'The first and third row are without my patches, once they are applied,
ARCH_ORIONbecomes a sub-option ofARCH_MULTIPLATFORM.So with your patches it's no longer possible to build a small kernel, correct?
Correct. I was a bit surprised at how much object code enabling
CONFIG_OFadds these days, it used to be a lot less, but you are right that disablingCONFIG_OFis not possible with the way thatARCH_MULTIPLATFORMis structured.
Quoted 4 lines
It was always the plan to move all orion5x machines over to use
CONFIG_OFeventually, so you get that overhead one way or another, and at least it looks like doing multiplatform on top of OF doesn't add any noticeable extra overhead (the total numbers are actually smaller).
So the message is that Linux just get's bigger...
Fortunately this patch is planned for 4.5, and 4.4 is going to be an LTS kernel.
Quoted 1 line
It may also be worth investigating what has made
CONFIG_OFso costly,
Probably because too much is done at runtime and too few things can be fixed at build time.
Quoted 1 line
maybe we can reduce this a bit again.
Probably not without turning the wheel backward :-(
So for the test: yes it works, but I'm unhappy with it.
Detlef
Quoted 11 lines · On Thursday 10 December 2015 23:00:24 Detlef Vollmann wrote:
Quoted 3 lines · Arnd Bergmann
Quoted 1 line · On Thursday 10 December 2015 22:14:25 Detlef Vollmann wrote:
On 12/10/15 21:59, Arnd Bergmann wrote:
It may also be worth investigating what has made
CONFIG_OFso costly,Probably because too much is done at runtime and too few things can be fixed at build time.
Quoted 1 line
maybe we can reduce this a bit again.
Probably not without turning the wheel backward :-(
So for the test: yes it works, but I'm unhappy with it.
I'm not too happy about adding 80kb to the uncompressed kernel image either. I've spent some more time now trying to find where we added the bloat. It's mainly in drivers, not in arch specific code, a kilobyte here and there eventually adds up, but the largest portion with a little over 50% of the total diff is drivers/of.
I don't expect to find a lot of low-hanging fruit there. For reference, see the diff of 'size -A' below.
Arnd
-orion5x_defconfig-dt/arch/arm/kernel/built-in.o :+orion5x_defconfig-nodt/arch/arm/kernel/built-in.o :
--
-Total 48034
+Total 46863
-orion5x_defconfig-dt/arch/arm/mm/built-in.o :+orion5x_defconfig-nodt/arch/arm/mm/built-in.o :
--
-Total 43680
+Total 43672
-orion5x_defconfig-dt/arch/arm/plat-orion/built-in.o :+orion5x_defconfig-nodt/arch/arm/plat-orion/built-in.o :
--
-Total 22131
+Total 22103
-orion5x_defconfig-dt/drivers/ata/built-in.o :+orion5x_defconfig-nodt/drivers/ata/built-in.o :
-Total 160244
+Total 159524
-orion5x_defconfig-dt/drivers/base/built-in.o :+orion5x_defconfig-nodt/drivers/base/built-in.o :
--
-Total 111366
+Total 109090
-orion5x_defconfig-dt/drivers/bus/built-in.o :+orion5x_defconfig-nodt/drivers/bus/built-in.o :
-Total 10151
+Total 8120
-orion5x_defconfig-dt/drivers/clk/built-in.o :+orion5x_defconfig-nodt/drivers/clk/built-in.o :
--
-Total 35514
+Total 29469
-orion5x_defconfig-dt/drivers/crypto/built-in.o :+orion5x_defconfig-nodt/drivers/crypto/built-in.o :
--
-Total 8712
+Total 8552
-orion5x_defconfig-dt/drivers/dma/built-in.o :+orion5x_defconfig-nodt/drivers/dma/built-in.o :
--
-Total 18939
+Total 16186
-orion5x_defconfig-dt/drivers/gpio/built-in.o :+orion5x_defconfig-nodt/drivers/gpio/built-in.o :
--
-Total 26663
+Total 19142
-orion5x_defconfig-dt/drivers/i2c/built-in.o :+orion5x_defconfig-nodt/drivers/i2c/built-in.o :
--
-Total 25772
+Total 23778
-orion5x_defconfig-dt/drivers/input/built-in.o :+orion5x_defconfig-nodt/drivers/input/built-in.o :
--
-Total 39847
+Total 38531
-orion5x_defconfig-dt/drivers/leds/built-in.o :+orion5x_defconfig-nodt/drivers/leds/built-in.o :
--
-Total 10436
+Total 10372
-orion5x_defconfig-dt/drivers/misc/built-in.o :+orion5x_defconfig-nodt/drivers/misc/built-in.o :
--
-Total 3163
+Total 1939
-orion5x_defconfig-dt/drivers/mtd/built-in.o :+orion5x_defconfig-nodt/drivers/mtd/built-in.o :
--
-Total 162074
+Total 157383
-orion5x_defconfig-dt/drivers/net/built-in.o :+orion5x_defconfig-nodt/drivers/net/built-in.o :
--
-Total 50038
+Total 46757
-orion5x_defconfig-dt/drivers/of/built-in.o :+orion5x_defconfig-nodt/drivers/of/built-in.o :
--
-Total 46444
+Total 0
-orion5x_defconfig-dt/drivers/pci/built-in.o :+orion5x_defconfig-nodt/drivers/pci/built-in.o :
--
-Total 115926
+Total 115352
-orion5x_defconfig-dt/drivers/perf/built-in.o :+orion5x_defconfig-nodt/drivers/perf/built-in.o :
--
-Total 4796
+Total 4202
-orion5x_defconfig-dt/drivers/phy/built-in.o :+orion5x_defconfig-nodt/drivers/phy/built-in.o :
--
-Total 5529
+Total 4909
-orion5x_defconfig-dt/drivers/rtc/built-in.o :+orion5x_defconfig-nodt/drivers/rtc/built-in.o :
--
-Total 35840
+Total 35024
-orion5x_defconfig-dt/drivers/tty/built-in.o :+orion5x_defconfig-nodt/drivers/tty/built-in.o :
--
-Total 125096
+Total 119738
-orion5x_defconfig-dt/drivers/usb/built-in.o :+orion5x_defconfig-nodt/drivers/usb/built-in.o :
--
-Total 251268
+Total 250498
+Josh
Hey Arnd, Detlef,
Quoted 11 lines · Arnd Bergmann
Quoted 10 lines · On Thursday 10 December 2015 23:00:24 Detlef Vollmann wrote:
Quoted 3 lines · Arnd Bergmann
Quoted 1 line · On Thursday 10 December 2015 22:14:25 Detlef Vollmann wrote:
On 12/10/15 21:59, Arnd Bergmann wrote:
It may also be worth investigating what has made
CONFIG_OFso costly,Probably because too much is done at runtime and too few things can be fixed at build time.
Quoted 1 line
maybe we can reduce this a bit again.
Probably not without turning the wheel backward :-(
Quoted 7 lines
Quoted 1 line
So for the test: yes it works, but I'm unhappy with it.
I'm not too happy about adding 80kb to the uncompressed kernel image either. I've spent some more time now trying to find where we added the bloat. It's mainly in drivers, not in arch specific code, a kilobyte here and there eventually adds up, but the largest portion with a little over 50% of the total diff is
drivers/of.
Wasn't there an idea kicked around a while ago to create a dt2boardfile script/executable*? Then, during kernel configuration, you enable it and select which dts file you want. It would disable CONFIG_OF, multiplatform, etc. And generate a board_file.c from the dts file.
If anything, it might be worth asking the kernel tinification [1], [2] folks if they'd be interested in taking this on...
thx,
Jason.
* This may have been completely in my head...
[1] http://events.linuxfoundation.org/sites/events/files/slides/tiny.pdf
[2] https://tiny.wiki.kernel.org/
Quoted 24 lines · On Friday 11 December 2015 13:36:01 Jason Cooper wrote:
+Josh
Hey Arnd, Detlef,
Quoted 11 lines · Arnd Bergmann
Quoted 10 lines · On Thursday 10 December 2015 23:00:24 Detlef Vollmann wrote:
Quoted 3 lines · Arnd Bergmann
Quoted 1 line · On Thursday 10 December 2015 22:14:25 Detlef Vollmann wrote:
On 12/10/15 21:59, Arnd Bergmann wrote:
It may also be worth investigating what has made
CONFIG_OFso costly,Probably because too much is done at runtime and too few things can be fixed at build time.
Quoted 1 line
maybe we can reduce this a bit again.
Probably not without turning the wheel backward
Quoted 7 lines
Quoted 1 line
So for the test: yes it works, but I'm unhappy with it.
I'm not too happy about adding 80kb to the uncompressed kernel image either. I've spent some more time now trying to find where we added the bloat. It's mainly in drivers, not in arch specific code, a kilobyte here and there eventually adds up, but the largest portion with a little over 50% of the total diff is
drivers/of.
Quoted 5 lines
Wasn't there an idea kicked around a while ago to create a dt2boardfile script/executable*? Then, during kernel configuration, you enable it and select which dts file you want. It would disable
CONFIG_OF, multiplatform, etc. And generate aboard_file.cfrom the dts file.
I think you are right this has come up in the past, but I don't see how it would work in practice without significant changes to driver subsystems:
The way we describe devices in DT is often very different from what we have for the traditional board files, and in some cases we don't even support platform data any more, so this would still depend on having properties according to the DT bindings, and require a large chunk of the same code that is doing DT at the moment.
Arnd
Quoted 31 lines · Arnd Bergmann
Quoted 24 lines · On Friday 11 December 2015 13:36:01 Jason Cooper wrote:
+Josh
Hey Arnd, Detlef,
Quoted 11 lines · Arnd Bergmann
Quoted 10 lines · On Thursday 10 December 2015 23:00:24 Detlef Vollmann wrote:
Quoted 3 lines · Arnd Bergmann
Quoted 1 line · On Thursday 10 December 2015 22:14:25 Detlef Vollmann wrote:
On 12/10/15 21:59, Arnd Bergmann wrote:
It may also be worth investigating what has made
CONFIG_OFso costly,Probably because too much is done at runtime and too few things can be fixed at build time.
Quoted 1 line
maybe we can reduce this a bit again.
Probably not without turning the wheel backward
Quoted 7 lines
Quoted 1 line
So for the test: yes it works, but I'm unhappy with it.
I'm not too happy about adding 80kb to the uncompressed kernel image either. I've spent some more time now trying to find where we added the bloat. It's mainly in drivers, not in arch specific code, a kilobyte here and there eventually adds up, but the largest portion with a little over 50% of the total diff is
drivers/of.Quoted 5 lines
Wasn't there an idea kicked around a while ago to create a dt2boardfile script/executable*? Then, during kernel configuration, you enable it and select which dts file you want. It would disable
CONFIG_OF, multiplatform, etc. And generate aboard_file.cfrom the dts file.
Quoted 8 lines
I think you are right this has come up in the past, but I don't see how it would work in practice without significant changes to driver subsystems:
The way we describe devices in DT is often very different from what we have for the traditional board files, and in some cases we don't even support platform data any more, so this would still depend on having properties according to the DT bindings, and require a large chunk of the same code that is doing DT at the moment.
yes, that's unfortunate. Perhaps the tinification links are still helpful to Detlef.
thx,
Jason.
cover ARM: orion5x/dove/mv78xx0 multiplatform
Quoted 4 lines · Jason Cooper
Quoted 3 lines · Arnd Bergmann
I think you are right this has come up in the past, but I don't see how it would work in practice without significant changes to driver subsystems:
Quoted 8 lines
Quoted 5 lines
The way we describe devices in DT is often very different from what we have for the traditional board files, and in some cases we don't even support platform data any more, so this would still depend on having properties according to the DT bindings, and require a large chunk of the same code that is doing DT at the moment.
yes, that's unfortunate. Perhaps the tinification links are still helpful to Detlef.
I've heard of the tinyfication project, but not paid too much attentions. I believe it's the wrong side around.
For busybox, patches that produce larger binaries without providing new functionality are just rejected.
Those that provide new functionality and such create bigger binaries must have a configuration option for still being able to get the old small binary.
If you accept patches that make the kernel bigger without a configuration option to avoid this, any tinyfication effort that tries to make the kernel small again afterwards is IMHO a noble but lost cause.
Detlef
Quoted 24 lines · Jason Cooper
+Josh
Hey Arnd, Detlef,
Quoted 11 lines · Arnd Bergmann
Quoted 10 lines · On Thursday 10 December 2015 23:00:24 Detlef Vollmann wrote:
Quoted 3 lines · Arnd Bergmann
Quoted 1 line · On Thursday 10 December 2015 22:14:25 Detlef Vollmann wrote:
On 12/10/15 21:59, Arnd Bergmann wrote:
It may also be worth investigating what has made
CONFIG_OFso costly,Probably because too much is done at runtime and too few things can be fixed at build time.
Quoted 1 line
maybe we can reduce this a bit again.
Probably not without turning the wheel backward :-(
Quoted 7 lines
Quoted 1 line
So for the test: yes it works, but I'm unhappy with it.
I'm not too happy about adding 80kb to the uncompressed kernel image either. I've spent some more time now trying to find where we added the bloat. It's mainly in drivers, not in arch specific code, a kilobyte here and there eventually adds up, but the largest portion with a little over 50% of the total diff is
drivers/of.
Quoted 8 lines
Wasn't there an idea kicked around a while ago to create a dt2boardfile script/executable*? Then, during kernel configuration, you enable it and select which dts file you want. It would disable
CONFIG_OF, multiplatform, etc. And generate aboard_file.cfrom the dts file.If anything, it might be worth asking the kernel tinification [1], [2] folks if they'd be interested in taking this on...
No objection if you want to add it to the task list on tiny.wiki.kernel.org (on the more difficult end).
I don't know if you could generate a board file, but I do wonder if you could effectively compile in a parsed description and ditch the parser. Bonus if you can make the values parsed out of it into compile-time constants for constant folding.
Quoted 31 lines · Josh Triplett
Quoted 30 lines · Jason Cooper
+Josh
Hey Arnd, Detlef,
Quoted 11 lines · Arnd Bergmann
Quoted 10 lines · On Thursday 10 December 2015 23:00:24 Detlef Vollmann wrote:
Quoted 3 lines · Arnd Bergmann
Quoted 1 line · On Thursday 10 December 2015 22:14:25 Detlef Vollmann wrote:
On 12/10/15 21:59, Arnd Bergmann wrote:
It may also be worth investigating what has made
CONFIG_OFso costly,Probably because too much is done at runtime and too few things can be fixed at build time.
Quoted 1 line
maybe we can reduce this a bit again.
Probably not without turning the wheel backward :-(
Quoted 7 lines
Quoted 1 line
So for the test: yes it works, but I'm unhappy with it.
I'm not too happy about adding 80kb to the uncompressed kernel image either. I've spent some more time now trying to find where we added the bloat. It's mainly in drivers, not in arch specific code, a kilobyte here and there eventually adds up, but the largest portion with a little over 50% of the total diff is
drivers/of.Wasn't there an idea kicked around a while ago to create a dt2boardfile script/executable*? Then, during kernel configuration, you enable it and select which dts file you want. It would disable
CONFIG_OF, multiplatform, etc. And generate aboard_file.cfrom the dts file.
Quoted 5 lines
Quoted 2 lines
If anything, it might be worth asking the kernel tinification [1], [2] folks if they'd be interested in taking this on...
No objection if you want to add it to the task list on tiny.wiki.kernel.org (on the more difficult end).
Done.
Quoted 4 lines
I don't know if you could generate a board file, but I do wonder if you could effectively compile in a parsed description and ditch the parser. Bonus if you can make the values parsed out of it into compile-time constants for constant folding.
After a bit of discussion with Arnd on irc, I agree. Going to a board file doesn't really work since the logic is now mostly in the drivers probe functions.
The dts parsing -> compile-time constants is worth looking into.
thx,
Jason.
Quoted 32 lines · Jason Cooper
Quoted 31 lines · Josh Triplett
Quoted 30 lines · Jason Cooper
+Josh
Hey Arnd, Detlef,
Quoted 11 lines · Arnd Bergmann
Quoted 10 lines · On Thursday 10 December 2015 23:00:24 Detlef Vollmann wrote:
Quoted 3 lines · Arnd Bergmann
Quoted 1 line · On Thursday 10 December 2015 22:14:25 Detlef Vollmann wrote:
On 12/10/15 21:59, Arnd Bergmann wrote:
It may also be worth investigating what has made
CONFIG_OFso costly,Probably because too much is done at runtime and too few things can be fixed at build time.
Quoted 1 line
maybe we can reduce this a bit again.
Probably not without turning the wheel backward :-(
Quoted 7 lines
Quoted 1 line
So for the test: yes it works, but I'm unhappy with it.
I'm not too happy about adding 80kb to the uncompressed kernel image either. I've spent some more time now trying to find where we added the bloat. It's mainly in drivers, not in arch specific code, a kilobyte here and there eventually adds up, but the largest portion with a little over 50% of the total diff is
drivers/of.Wasn't there an idea kicked around a while ago to create a dt2boardfile script/executable*? Then, during kernel configuration, you enable it and select which dts file you want. It would disable
CONFIG_OF, multiplatform, etc. And generate aboard_file.cfrom the dts file.
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
If anything, it might be worth asking the kernel tinification [1], [2] folks if they'd be interested in taking this on...
No objection if you want to add it to the task list on tiny.wiki.kernel.org (on the more difficult end).
Done.
Can you add yourself as a potential contact for that project?
Quoted 14 lines
Quoted 4 lines
I don't know if you could generate a board file, but I do wonder if you could effectively compile in a parsed description and ditch the parser. Bonus if you can make the values parsed out of it into compile-time constants for constant folding.
After a bit of discussion with Arnd on irc, I agree. Going to a board file doesn't really work since the logic is now mostly in the drivers probe functions.
The dts parsing -> compile-time constants is worth looking into.
thx,
Jason.
Hey Josh,
Quoted 2 lines · Josh Triplett
Quoted 1 line · Jason Cooper
On Fri, Dec 11, 2015 at 10:27:30AM -0800, Josh Triplett wrote:
...
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
No objection if you want to add it to the task list on tiny.wiki.kernel.org (on the more difficult end).
Done.
Can you add yourself as a potential contact for that project?
Updated.
thx,
Jason.
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 4 lines · On Thursday 10 December 2015 14:39:27 Detlef Vollmann wrote:
#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 4.4.0-rc3 Kernel Configuration
#
Just for fun, a few things you can probably disable without much downsides:
Quoted 4 lines
CONFIG_DEFAULT_HOSTNAME="dns-323"CONFIG_SWAP=yCONFIG_SYSVIPC=yCONFIG_SYSVIPC_SYSCTL=y
SYSVIPC could be disabled in principle for most embedded systems
Quoted 5 lines
CONFIG_SYSFS_DEPRECATED=yCONFIG_SYSFS_DEPRECATED_V2=y
#CONFIG_RELAYis not setCONFIG_BLK_DEV_INITRD=yCONFIG_INITRAMFS_SOURCE=""
SYSFS_DEPRECATED can probably go, initramfs would be smaller than initrd
Quoted 8 lines
CONFIG_COMPAT_BRK=yCONFIG_SLAB=y
#CONFIG_SLUBis not set
#CONFIG_SLOBis not set
#CONFIG_SYSTEM_DATA_VERIFICATIONis not set
#CONFIG_PROFILINGis not setCONFIG_KEXEC_CORE=yCONFIG_HAVE_OPROFILE=y
SLOB would be smaller than SLAB, kexec is often not needed.
Quoted 2 lines
CONFIG_SWIOTLB=yCONFIG_IOMMU_HELPER=y
I have no idea why SWIOTLB is always enabled on ARM, I suspect that's a bug, and disabling it would save some space (need to change arm/Kconfig)
Quoted 5 lines
#
# User Modules And Translation Layers
#CONFIG_MTD_BLKDEVS=yCONFIG_MTD_BLOCK=y
I suspect you don't use MTD_BLOCK
Quoted 6 lines
CONFIG_BLK_DEV=y
#CONFIG_BLK_DEV_NULL_BLKis not set
#CONFIG_BLK_DEV_PCIESSD_MTIP32XXis not set
#CONFIG_BLK_CPQ_CISS_DAis not set
#CONFIG_BLK_DEV_DAC960is not set
#CONFIG_BLK_DEV_UMEMis not set
Quoted 8 lines
#
CONFIG_BLK_DEV_COW_COMMONis not setCONFIG_BLK_DEV_LOOP=yCONFIG_BLK_DEV_LOOP_MIN_COUNT=4
#CONFIG_BLK_DEV_CRYPTOLOOPis not set
#CONFIG_BLK_DEV_DRBDis not set
#CONFIG_BLK_DEV_NBDis not set
#CONFIG_BLK_DEV_SX8is not setCONFIG_BLK_DEV_RAM=y
Loop and RAM could be loadable modules, if that saves space in the end. If modules are actually larger, you can have everything built-in.
Quoted 5 lines
#
# Serial drivers
#CONFIG_SERIAL_EARLYCON=yCONFIG_SERIAL_8250=y
Quoted 8 lines
#
CONFIG_SERIAL_8250_DEPRECATED_OPTIONSis not setCONFIG_SERIAL_8250_CONSOLE=yCONFIG_SERIAL_8250_DMA=y
#CONFIG_SERIAL_8250_PCIis not setCONFIG_SERIAL_8250_NR_UARTS=2CONFIG_SERIAL_8250_RUNTIME_UARTS=2
#CONFIG_SERIAL_8250_EXTENDEDis not setCONFIG_SERIAL_8250_FSL=y
No need for 8250_FSL or 8250_DMA on your hardware
Quoted 6 lines
#
# Memory mapped GPIO drivers
#
#CONFIG_GPIO_74XX_MMIOis not set
#CONFIG_GPIO_ALTERAis not set
#CONFIG_GPIO_DWAPBis not set
Quoted 8 lines
#
CONFIG_GPIO_EMis not set
#CONFIG_GPIO_GENERIC_PLATFORMis not set
#CONFIG_GPIO_GRGPIOis not setCONFIG_GPIO_MVEBU=y
#CONFIG_GPIO_VX855is not set
#CONFIG_GPIO_XILINXis not set
#CONFIG_GPIO_ZEVIOis not set
#CONFIG_GPIO_ZXis not set
It looks like you get two GPIO drivers for the same hardware. We should probably change this so you only need one of the two.
Quoted 10 lines
#
# USB Host Controller Drivers
#
#CONFIG_USB_C67X00_HCDis not set
#CONFIG_USB_XHCI_HCDis not setCONFIG_USB_EHCI_HCD=yCONFIG_USB_EHCI_ROOT_HUB_TT=y
#CONFIG_USB_EHCI_TT_NEWSCHEDis not setCONFIG_USB_EHCI_PCI=yCONFIG_USB_EHCI_HCD_ORION=y
You probably don't have a PCI EHCI
Quoted 1 line
CONFIG_USB_STORAGE=y
module
Quoted 4 lines
#
# PHY Subsystem
#CONFIG_GENERIC_PHY=y
probably not needed since you have no specific driver for it.
Quoted 6 lines
#
# File systems
#CONFIG_EXT2_FS=yCONFIG_EXT2_FS_XATTR=yCONFIG_EXT2_FS_POSIX_ACL=y
EXT2 no longer needs to be built when EXT4 is enabled, you can just use the EXT4 code to mount EXT2 file systems.
Quoted 2 lines
CONFIG_XFS_FS=y
#CONFIG_XFS_QUOTAis not set
XFS is huge. If you don't need it, that would likely save more than anything else.
Quoted 1 line
CONFIG_MINIX_FS=y
minixfs is almost never needed, but small.
Quoted 4 lines
#
CONFIG_OMFS_FSis not set
#CONFIG_HPFS_FSis not set
#CONFIG_QNX4FS_FSis not set
#CONFIG_QNX6FS_FSis not set
Quoted 8 lines
#
CONFIG_ROMFS_FSis not set
#CONFIG_PSTOREis not set
#CONFIG_SYSV_FSis not set
#CONFIG_UFS_FSis not setCONFIG_NETWORK_FILESYSTEMS=yCONFIG_NFS_FS=yCONFIG_NFS_V2=yCONFIG_NFS_V3=y
NFS and NFSD are also pretty big, but I assume you need them.
Arnd
cover ARM: orion5x/dove/mv78xx0 multiplatform
Quoted 9 lines · Arnd Bergmann
Quoted 4 lines · On Thursday 10 December 2015 14:39:27 Detlef Vollmann wrote:
#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 4.4.0-rc3 Kernel Configuration
#Just for fun, a few things you can probably disable without much downsides:
Quoted 6 lines
Quoted 4 lines
CONFIG_DEFAULT_HOSTNAME="dns-323"CONFIG_SWAP=yCONFIG_SYSVIPC=yCONFIG_SYSVIPC_SYSCTL=ySYSVIPC could be disabled in principle for most embedded systems
I was a big fan of SYSV IPC and still sometimes prefer SYSV shm over mmap. But yes, for this system I probably don't need it. (Though I have a dim memory that one of the userspace programs required it, but I will try without again.)
I need swap for the case I have hard disks mounted and run checks on them.
Quoted 7 lines
Quoted 5 lines
CONFIG_SYSFS_DEPRECATED=yCONFIG_SYSFS_DEPRECATED_V2=y
#CONFIG_RELAYis not setCONFIG_BLK_DEV_INITRD=yCONFIG_INITRAMFS_SOURCE=""
SYSFS_DEPRECATEDcan probably go,
Probably yes.
Quoted 1 line
initramfs would be smaller than initrd
But initramfs doesn't accept a squashfs.
The trick here is that the same squashfs is first used as initrd and then as rootfs directly from flash (and the RAM of the initrd is freed then).
Quoted 10 lines
Quoted 8 lines
CONFIG_COMPAT_BRK=yCONFIG_SLAB=y
#CONFIG_SLUBis not set
#CONFIG_SLOBis not set
#CONFIG_SYSTEM_DATA_VERIFICATIONis not set
#CONFIG_PROFILINGis not setCONFIG_KEXEC_CORE=yCONFIG_HAVE_OPROFILE=ySLOB would be smaller than SLAB,
I didn't know this.
Quoted 1 line
kexec is often not needed.
This is the way I test new kernels.
I don't have JTAG mounted on this device and therefore don't want to risk to replace the U-Boot. Unfortunately the installed U-Boot doesn't support the network and uploading kernel and initrd through the serial port isn't very reliable...
Quoted 5 lines
Quoted 2 lines
CONFIG_SWIOTLB=yCONFIG_IOMMU_HELPER=yI have no idea why SWIOTLB is always enabled on ARM, I suspect that's a bug, and disabling it would save some space (need to change arm/Kconfig)
Ok, I'll test it.
Quoted 7 lines
Quoted 5 lines
#
# User Modules And Translation Layers
#CONFIG_MTD_BLKDEVS=yCONFIG_MTD_BLOCK=yI suspect you don't use
MTD_BLOCK
I believe SQUASHFS as well as MINIX FS require it.
Quoted 15 lines
Quoted 6 lines
CONFIG_BLK_DEV=y
#CONFIG_BLK_DEV_NULL_BLKis not set
#CONFIG_BLK_DEV_PCIESSD_MTIP32XXis not set
#CONFIG_BLK_CPQ_CISS_DAis not set
#CONFIG_BLK_DEV_DAC960is not set
#CONFIG_BLK_DEV_UMEMis not setQuoted 8 lines
#
CONFIG_BLK_DEV_COW_COMMONis not setCONFIG_BLK_DEV_LOOP=yCONFIG_BLK_DEV_LOOP_MIN_COUNT=4
#CONFIG_BLK_DEV_CRYPTOLOOPis not set
#CONFIG_BLK_DEV_DRBDis not set
#CONFIG_BLK_DEV_NBDis not set
#CONFIG_BLK_DEV_SX8is not setCONFIG_BLK_DEV_RAM=y
Quoted 2 lines
Loop and RAM could be loadable modules, if that saves space in the end. If modules are actually larger, you can have everything built-in.
The flash partitioning is fix on this system (without my own U-Boot). So I pushed as much as possible into the kernel binary to save the other partition for real userspace programs. I didn't succeed (XFS and btrfs are too big) but still try to cram as much as possible into the kernel binary. My current rootfs spare is less than 100K and I need to care for updates...
Quoted 14 lines
Quoted 5 lines
#
# Serial drivers
#CONFIG_SERIAL_EARLYCON=yCONFIG_SERIAL_8250=yQuoted 8 lines
#
CONFIG_SERIAL_8250_DEPRECATED_OPTIONSis not setCONFIG_SERIAL_8250_CONSOLE=yCONFIG_SERIAL_8250_DMA=y
#CONFIG_SERIAL_8250_PCIis not setCONFIG_SERIAL_8250_NR_UARTS=2CONFIG_SERIAL_8250_RUNTIME_UARTS=2
#CONFIG_SERIAL_8250_EXTENDEDis not setCONFIG_SERIAL_8250_FSL=y
Quoted 1 line
No need for 8250_FSL or 8250_DMA on your hardware
Thanks (I don't have proper documentation for this CPU).
Quoted 15 lines
Quoted 6 lines
#
# Memory mapped GPIO drivers
#
#CONFIG_GPIO_74XX_MMIOis not set
#CONFIG_GPIO_ALTERAis not set
#CONFIG_GPIO_DWAPBis not setQuoted 8 lines
#
CONFIG_GPIO_EMis not set
#CONFIG_GPIO_GENERIC_PLATFORMis not set
#CONFIG_GPIO_GRGPIOis not setCONFIG_GPIO_MVEBU=y
#CONFIG_GPIO_VX855is not set
#CONFIG_GPIO_XILINXis not set
#CONFIG_GPIO_ZEVIOis not set
#CONFIG_GPIO_ZXis not set
Quoted 2 lines
It looks like you get two GPIO drivers for the same hardware. We should probably change this so you only need one of the two.
Yes. I was surprised when I saw GPIO_MVEBU but ARCH_ORION5X turns it always on.
Quoted 11 lines
Quoted 10 lines
#
# USB Host Controller Drivers
#
#CONFIG_USB_C67X00_HCDis not set
#CONFIG_USB_XHCI_HCDis not setCONFIG_USB_EHCI_HCD=yCONFIG_USB_EHCI_ROOT_HUB_TT=y
#CONFIG_USB_EHCI_TT_NEWSCHEDis not setCONFIG_USB_EHCI_PCI=yCONFIG_USB_EHCI_HCD_ORION=y
Quoted 5 lines
You probably don't have a PCI EHCI
Quoted 1 line
CONFIG_USB_STORAGE=ymodule
I want to be able to run the rootfs from USB as a fallback.
Quoted 6 lines
Quoted 4 lines
#
# PHY Subsystem
#CONFIG_GENERIC_PHY=yprobably not needed since you have no specific driver for it.
Thanks.
Quoted 9 lines
Quoted 6 lines
#
# File systems
#CONFIG_EXT2_FS=yCONFIG_EXT2_FS_XATTR=yCONFIG_EXT2_FS_POSIX_ACL=yEXT2 no longer needs to be built when EXT4 is enabled, you can just use the EXT4 code to mount EXT2 file systems.
Right now I have a bug with EXT4 (I can't delete a 200GB file). So I probably trust the EXT2 code more (but I still want to be able to have an EXT4 FS).
Quoted 5 lines
Quoted 2 lines
CONFIG_XFS_FS=y
#CONFIG_XFS_QUOTAis not setXFS is huge. If you don't need it, that would likely save more than anything else.
I know. And btrfs is even worse (most features can't be configured off). But this is a backup station and I want the options of the different filesystems.
Quoted 3 lines
Quoted 1 line
CONFIG_MINIX_FS=yminixfs is almost never needed, but small.
There are two flash partitions with the persistent system parameters. These use MINIX FS (not my design).
Quoted 13 lines
Quoted 4 lines
#
CONFIG_OMFS_FSis not set
#CONFIG_HPFS_FSis not set
#CONFIG_QNX4FS_FSis not set
#CONFIG_QNX6FS_FSis not setQuoted 8 lines
#
CONFIG_ROMFS_FSis not set
#CONFIG_PSTOREis not set
#CONFIG_SYSV_FSis not set
#CONFIG_UFS_FSis not setCONFIG_NETWORK_FILESYSTEMS=yCONFIG_NFS_FS=yCONFIG_NFS_V2=yCONFIG_NFS_V3=y
Quoted 1 line
NFS and NFSD are also pretty big, but I assume you need them.
Yes.
Thanks for your effort, but some time ago I hoped to get rid of all modules (to save some space for userspace) and went through the whole configuration. So there are at least no big chunks to be removed...
Detlef
Quoted 19 lines · Gregory CLEMENT
Hi Arnd,
Quoted 10 lines · Arnd Bergmann
I've posted these before and now gotten around to a rebase and want to include them in the arm-soc next/multiplatform branch for 4.5.
Originally the plan for these platforms was to convert all of them to DT and use only mach-mvebu. That has not happened, so I would do it this way instead so we can at least have them in a single kernel.
Let me know if there are any concerns or objections.
I have applied all the patches on mvebu/oldmvebu_multiplatform (I fixed the last one which didn't apply on
Kconfig). I also merged it mvebu/for-netx to be part of the linux-next.
Quoted 5 lines
But before making it part of mvebu/soc, I would like to get some Tested-by. The series is available on
git://git.infradead.org/linux-mvebu.git
in the branch mvebu/oldmvebu_multiplatform but it also will be part soon of linux-next.
Hi Gregory
I blew the dust of my Orion5x NAS Reference Design. It boots.
It would be nice to make Orion5x part of the multi_v5_defconfig and mvebu_v5_defconfig. I will see about cooking up some patches.
Andrew
Quoted 26 lines · On Tuesday 01 December 2015 23:51:26 Andrew Lunn wrote:
Quoted 19 lines · Gregory CLEMENT
Hi Arnd,
Quoted 10 lines · Arnd Bergmann
I've posted these before and now gotten around to a rebase and want to include them in the arm-soc next/multiplatform branch for 4.5.
Originally the plan for these platforms was to convert all of them to DT and use only mach-mvebu. That has not happened, so I would do it this way instead so we can at least have them in a single kernel.
Let me know if there are any concerns or objections.
I have applied all the patches on mvebu/oldmvebu_multiplatform (I fixed the last one which didn't apply on
Kconfig). I also merged it mvebu/for-netx to be part of the linux-next.Quoted 5 lines
But before making it part of mvebu/soc, I would like to get some Tested-by. The series is available on
git://git.infradead.org/linux-mvebu.git
in the branch mvebu/oldmvebu_multiplatform but it also will be part soon of linux-next.
Quoted 5 lines
Hi Gregory
I blew the dust of my Orion5x NAS Reference Design. It boots.
Tested-by Andrew Lunn <[email protected]>
Thanks for testing!
Quoted 2 lines
It would be nice to make Orion5x part of the
multi_v5_defconfigandmvebu_v5_defconfig. I will see about cooking up some patches.
Good idea.
Arnd
Hi Andrew,
Quoted 26 lines · Andrew Lunn
Quoted 19 lines · Gregory CLEMENT
Hi Arnd,
Quoted 10 lines · Arnd Bergmann
I've posted these before and now gotten around to a rebase and want to include them in the arm-soc next/multiplatform branch for 4.5.
Originally the plan for these platforms was to convert all of them to DT and use only mach-mvebu. That has not happened, so I would do it this way instead so we can at least have them in a single kernel.
Let me know if there are any concerns or objections.
I have applied all the patches on mvebu/oldmvebu_multiplatform (I fixed the last one which didn't apply on
Kconfig). I also merged it mvebu/for-netx to be part of the linux-next.Quoted 5 lines
But before making it part of mvebu/soc, I would like to get some Tested-by. The series is available on
git://git.infradead.org/linux-mvebu.git
in the branch mvebu/oldmvebu_multiplatform but it also will be part soon of linux-next.
Quoted 3 lines
Hi Gregory
I blew the dust of my Orion5x NAS Reference Design. It boots.
Great!
Thanks for testing
Gregory
Quoted 7 lines
Tested-by Andrew Lunn <[email protected]>It would be nice to make Orion5x part of the
multi_v5_defconfigandmvebu_v5_defconfig. I will see about cooking up some patches.Andrew
Signature · 4 lines
Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
Quoted 25 lines · Gregory CLEMENT
Hi Arnd,
Quoted 10 lines · Arnd Bergmann
I've posted these before and now gotten around to a rebase and want to include them in the arm-soc next/multiplatform branch for 4.5.
Originally the plan for these platforms was to convert all of them to DT and use only mach-mvebu. That has not happened, so I would do it this way instead so we can at least have them in a single kernel.
Let me know if there are any concerns or objections.
I have applied all the patches on mvebu/oldmvebu_multiplatform (I fixed the last one which didn't apply on
Kconfig). I also merged it mvebu/for-netx to be part of the linux-next.But before making it part of mvebu/soc, I would like to get some Tested-by. The series is available on
git://git.infradead.org/linux-mvebu.git
in the branch mvebu/oldmvebu_multiplatform but it also will be part soon of linux-next.
Quoted 3 lines
Russell, Sebastian,
would you have some time to test it on Dove?
Given that I'm testing on my Cubox tree, I've applied this series on top of v4.3. Patch 5 trivially conflicts on MMP context. Fixing that and merging the resulting changes gives another load of conflicts which need dealing with:
Recorded preimage for 'arch/arm/Kconfig' Recorded preimage for 'arch/arm/mach-dove/Kconfig' Recorded preimage for 'arch/arm/mach-dove/irq.c' Recorded preimage for 'arch/arm/mach-dove/pm.h'
These look less trivial to resolve, so testing this will have to wait until I have sufficient time to sort this out.
Signature · 2 lines
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
Quoted 35 lines · On Wednesday 02 December 2015 12:33:10 Russell King - ARM Linux wrote:
Quoted 25 lines · Gregory CLEMENT
Hi Arnd,
Quoted 10 lines · Arnd Bergmann
I've posted these before and now gotten around to a rebase and want to include them in the arm-soc next/multiplatform branch for 4.5.
Originally the plan for these platforms was to convert all of them to DT and use only mach-mvebu. That has not happened, so I would do it this way instead so we can at least have them in a single kernel.
Let me know if there are any concerns or objections.
I have applied all the patches on mvebu/oldmvebu_multiplatform (I fixed the last one which didn't apply on
Kconfig). I also merged it mvebu/for-netx to be part of the linux-next.But before making it part of mvebu/soc, I would like to get some Tested-by. The series is available on
git://git.infradead.org/linux-mvebu.git
in the branch mvebu/oldmvebu_multiplatform but it also will be part soon of linux-next.Quoted 3 lines
Russell, Sebastian,
would you have some time to test it on Dove?
Given that I'm testing on my Cubox tree, I've applied this series on top of v4.3. Patch 5 trivially conflicts on MMP context. Fixing that and merging the resulting changes gives another load of conflicts which need dealing with:
Quoted 7 lines
Recorded preimage for '
arch/arm/Kconfig' Recorded preimage for 'arch/arm/mach-dove/Kconfig' Recorded preimage for 'arch/arm/mach-dove/irq.c' Recorded preimage for 'arch/arm/mach-dove/pm.h'These look less trivial to resolve, so testing this will have to wait until I have sufficient time to sort this out.
I have pushed a rebased version to git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git multiplatform-orion-4.3
Maybe that helps
Arnd
Quoted 41 lines · Arnd Bergmann
Quoted 40 lines · On Wednesday 02 December 2015 12:33:10 Russell King - ARM Linux wrote:
Quoted 25 lines · Gregory CLEMENT
Hi Arnd,
Quoted 10 lines · Arnd Bergmann
I've posted these before and now gotten around to a rebase and want to include them in the arm-soc next/multiplatform branch for 4.5.
Originally the plan for these platforms was to convert all of them to DT and use only mach-mvebu. That has not happened, so I would do it this way instead so we can at least have them in a single kernel.
Let me know if there are any concerns or objections.
I have applied all the patches on mvebu/oldmvebu_multiplatform (I fixed the last one which didn't apply on
Kconfig). I also merged it mvebu/for-netx to be part of the linux-next.But before making it part of mvebu/soc, I would like to get some Tested-by. The series is available on
git://git.infradead.org/linux-mvebu.git
in the branch mvebu/oldmvebu_multiplatform but it also will be part soon of linux-next.Quoted 3 lines
Russell, Sebastian,
would you have some time to test it on Dove?
Given that I'm testing on my Cubox tree, I've applied this series on top of v4.3. Patch 5 trivially conflicts on MMP context. Fixing that and merging the resulting changes gives another load of conflicts which need dealing with:
Recorded preimage for '
arch/arm/Kconfig' Recorded preimage for 'arch/arm/mach-dove/Kconfig' Recorded preimage for 'arch/arm/mach-dove/irq.c' Recorded preimage for 'arch/arm/mach-dove/pm.h'
Quoted 7 lines
Quoted 2 lines
These look less trivial to resolve, so testing this will have to wait until I have sufficient time to sort this out.
I have pushed a rebased version to git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git multiplatform-orion-4.3
Maybe that helps
As I said above, that's not the problem, the problem is merging it into the rest of my tree.
Having done most of that merge, I'm now tripping up on:
arch/arm/mach-dove/common.c: In function 'dove_wdt_init':arch/arm/mach-dove/common.c:538:2: error: implicit declaration of function 'orion_wdt_init' [-Werror=implicit-function-declaration]
which I guess is because you've deleted the legacy orion watchdog stuff. So I'm going to have to revert that. That then gives me:
arch/arm/mach-dove/clock.c:19:21: fatal error: mach/pm.h: No such file or directory arch/arm/mach-dove/clock.c:20:27: fatal error: mach/hardware.h: No such file or directory
The first is easy to solve, and the second by replacing it with dove.h. The next problem is this:
arch/arm/plat-orion/common.c:25:30: fatal error: mach/bridge-regs.h: No such file or directory
which is impossible to solve, because plat-orion/common.c wants mach-dove/bridge-regs.h.
I also have arch/arm/mach-dove/include/mach/sdhci.h to pass the GPIO for card detection to the SDHCI driver, which is going to break unless it's moved to include/linux/platform-data.
Everything else seems mostly happy, but I've no way to tell whether what would be the resulting kernel would work as it's impossible to know without fixing the wreckage above.
I'm sure I don't have to repeat my position over what I'm going to do if these petty mainline changes which are totally unnecessary break the only setup I have which works. Making mach-dove multi-platform is a "wouldn't it be nice if", it's not an absolute necessity.
Signature · 2 lines
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
Quoted 7 lines · Russell King - ARM Linux
The first is easy to solve, and the second by replacing it with
dove.h. The next problem is this:
arch/arm/plat-orion/common.c:25:30: fatal error:mach/bridge-regs.h: No such file or directorywhich is impossible to solve, because
plat-orion/common.cwantsmach-dove/bridge-regs.h.
Another few breakages which is going to be difficult to solve:
drivers/hwmon/dove.c:35:30: fatal error: mach/bridge-regs.h: No such file or directory
drivers/soc/dove/pmu.c: In function 'dove_init_pmu_legacy':drivers/soc/dove/pmu.c:404:46: error: 'IRQ_DOVE_PMU_START' undeclared (first use in this function) drivers/soc/dove/pmu.c:404:46: note: each undeclared identifier is reported only once for each function it appears in
So, all in all this series gets a NAK from me as it totally destroys my ability to do any further work on Dove.
Signature · 2 lines
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
Quoted 11 lines · On Wednesday 02 December 2015 19:37:08 Russell King - ARM Linux wrote:
Quoted 7 lines · Russell King - ARM Linux
The first is easy to solve, and the second by replacing it with
dove.h. The next problem is this:
arch/arm/plat-orion/common.c:25:30: fatal error:mach/bridge-regs.h: No such file or directorywhich is impossible to solve, because
plat-orion/common.cwantsmach-dove/bridge-regs.h.Another few breakages which is going to be difficult to solve:
Quoted 9 lines
drivers/hwmon/dove.c:35:30: fatal error:mach/bridge-regs.h: No such file or directory
drivers/soc/dove/pmu.c: In function 'dove_init_pmu_legacy':drivers/soc/dove/pmu.c:404:46: error: 'IRQ_DOVE_PMU_START' undeclared (first use in this function)drivers/soc/dove/pmu.c:404:46: note: each undeclared identifier is reported only once for each function it appears inSo, all in all this series gets a NAK from me as it totally destroys my ability to do any further work on Dove.
Ok, I'll try to take out the dove specific parts that get in the way here but would still do the whole series for mv78xx0 and orion5x unless someone finds problems.
Arnd
Quoted 15 lines · On Wednesday 02 December 2015 19:28:25 Russell King - ARM Linux wrote:
As I said above, that's not the problem, the problem is merging it into the rest of my tree.
Having done most of that merge, I'm now tripping up on:
arch/arm/mach-dove/common.c: In function 'dove_wdt_init':arch/arm/mach-dove/common.c:538:2: error: implicit declaration of function 'orion_wdt_init' [-Werror=implicit-function-declaration]which I guess is because you've deleted the legacy orion watchdog stuff. So I'm going to have to revert that. That then gives me:
arch/arm/mach-dove/clock.c:19:21: fatal error:mach/pm.h: No such file or directoryarch/arm/mach-dove/clock.c:20:27: fatal error:mach/hardware.h: No such file or directory
Quoted 7 lines
The first is easy to solve, and the second by replacing it with
dove.h. The next problem is this:
arch/arm/plat-orion/common.c:25:30: fatal error:mach/bridge-regs.h: No such file or directorywhich is impossible to solve, because
plat-orion/common.cwantsmach-dove/bridge-regs.h.
Ok, I can try to work around that, either by duplicating the device definition, or passing the address into orion_wdt_init.
Quoted 3 lines
I also have
arch/arm/mach-dove/include/mach/sdhci.hto pass the GPIO for card detection to the SDHCI driver, which is going to break unless it's moved toinclude/linux/platform-data.
Right, a platform_data file seems the right approach there. Possibly just passing the gpio number by casting it to a pointer, though that's a bit ugly.
Quoted 8 lines
Everything else seems mostly happy, but I've no way to tell whether what would be the resulting kernel would work as it's impossible to know without fixing the wreckage above.
I'm sure I don't have to repeat my position over what I'm going to do if these petty mainline changes which are totally unnecessary break the only setup I have which works. Making mach-dove multi-platform is a "wouldn't it be nice if", it's not an absolute necessity.
I'm mostly interested in it because it's the only ARMv7 platform that is left after my other patches, and I just want to be done with it after spending 5 years on it ;-)
Arnd
Quoted 3 lines · Arnd Bergmann
I'm mostly interested in it because it's the only ARMv7 platform that is left after my other patches, and I just want to be done with it after spending 5 years on it ;-)
My understanding is that the long term goal is to delete mach-dove once everyone has settled down into the mvebu DT world.
Right now we have mvebu which covers Dove using DT. We have mach-dove which is legacy non-DT Dove.
It seems to me to be completely crazy to want to bring legacy code, which is ultimately destined to be deleted, into multiplatform.
Signature · 2 lines
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
Andrew Lunn
maintainerQuoted 5 lines · Russell King - ARM Linux
Quoted 3 lines · Arnd Bergmann
I'm mostly interested in it because it's the only ARMv7 platform that is left after my other patches, and I just want to be done with it after spending 5 years on it ;-)
Quoted 8 lines
My understanding is that the long term goal is to delete mach-dove once everyone has settled down into the mvebu DT world.
Right now we have mvebu which covers Dove using DT. We have mach-dove which is legacy non-DT Dove.
It seems to me to be completely crazy to want to bring legacy code, which is ultimately destined to be deleted, into multiplatform.
I agree. We have multiplatform dove already, it is in mach-mvebu. Do we really need both mach-dove and mach-mvebu dove in one kernel?
Andrew
Quoted 2 lines · Andrew Lunn
I agree. We have multiplatform dove already, it is in mach-mvebu. Do we really need both mach-dove and mach-mvebu dove in one kernel?
Only to support my efforts in adding further Dove support. As you know, we've recently added PMU support, and I've recently sent you patches for the remaining clocks. Both of those are laying the foundations for the next big piece, which is support for the GPU on Dove.
Most of the effort that's been going on recently has been for the GPU support has been invisible to most people, because much of that is around hammering out the DRM API for it, and getting the thing stable. This is a bigger project than just Dove, other SoCs also have the same GPU family in them, even having multiple separate GPU cores. It's taken a lot of effort and time to hammer this out between three people Lucas, Christian, and myself.
Some of the problems are only visible using the graphics stack which I have: xf86-video-armada (which is 2D GPU accelerated for any of these GPUs which support it) vs Christian's MESA (which obviously uses the 3D GPU.) On Dove, it's fairly simple, because the GPU core there is a combined 2D/3D affair, but iMX6 has separate cores, so I've had to come up with a way to synchronise between the cores (which obviously can have an effect on the user API, and therefore must be resolved prior to the initial submission.)
The mach-dove code is key to my involvement with this.
So, please realise that things have been _real_ busy on Dove, even though you have not seen much from me: that'll be quite normal when most of the effort is going on outside of something being Dove platform specific.
What Lucas and myself have been working towards since 4.2 is to get the kernel GPU driver into a state where we can get it merged: we've had the DRM people review it, and they've provided feedback. It's taken a long time to work through that feedback, which included totally ripping out the existing locking and replacing it with a completely new locking scheme
- which is never an easy thing to do. (Lucas had a few goes, I also had a few goes, and eventually we ended up with something that is fairly sane but has one very hairy place which was difficult to solve.)
Getting this sorted so I can then drop the galcore chunk of code out of my dove tree will be a major step forwards for me, and will allow me to eliminate the reason that I've not been willing to publish the tree in full (because, despite galcore being a supposedly open source kernel driver which lots of people - including companies - seem happy to distribute, there is at least one file in it which do not carry the open source boilerplate, but instead carry a more restrictive license, which as far as I'm concerned makes me unable to publish this code.)
Talking about publishing... I do wonder what use that would be. A while back, people were asking me to publish it, and I arranged to publish as much as I could, which included BMM, vmeta, PMU and other associated components. The result of that came to nothing at all, except a more complicated git tree for me to manage which has added to my workload, and thus slowed me down more... in hind sight, I don't know why I bothered.
Signature · 2 lines
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
Quoted 9 lines · On Wednesday 02 December 2015 21:38:10 Andrew Lunn wrote:
Quoted 8 lines · Russell King - ARM Linux
Quoted 3 lines · Arnd Bergmann
I'm mostly interested in it because it's the only ARMv7 platform that is left after my other patches, and I just want to be done with it after spending 5 years on it
My understanding is that the long term goal is to delete mach-dove once everyone has settled down into the mvebu DT world.
Quoted 8 lines
Quoted 5 lines
Right now we have mvebu which covers Dove using DT. We have mach-dove which is legacy non-DT Dove.
It seems to me to be completely crazy to want to bring legacy code, which is ultimately destined to be deleted, into multiplatform.
I agree. We have multiplatform dove already, it is in mach-mvebu. Do we really need both mach-dove and mach-mvebu dove in one kernel?
I'm also fine with deleting mach-dove, but that would be much more disruptive to Russell's work, so I don't think that helps anyone.
I've rebased the series to leave out the last two patches for dove, and added the watchdog on dove, so I can at least get the other patches out of my queue if that works for now.
Arnd
Andrew Lunn
maintainerQuoted 4 lines
Quoted 2 lines
I agree. We have multiplatform dove already, it is in mach-mvebu. Do we really need both mach-dove and mach-mvebu dove in one kernel?
I'm also fine with deleting mach-dove.
Ah, maybe i worded that badly. By "in one kernel" i mean kernel binary. We should keep mach-dove, and allow a mach-dove build of the kernel. But there is no reason for that build to be multi-platform. We already have multi-platform dove via mvebu.
Anyway, i see your v2 patches do leave mach-dove as a single platform kernel.
Andrew