ARM: support for Moschip MCS814x SoCs
Subsystems (3)
cover ARM: support for Moschip MCS814x SoCs
Hi all,
This patchset adds basic support for Mocship MCS814x, and in particular MCS8140, and allows one booting to user space. Two off-the-shelf boards are support: Tigal/Robotech RBT-832 and Devolo dLAN USB Extender.
Support for other on-board peripherals will obviously be contributed later once the basic SoC support has been accepted.
Florian Fainelli (8):
ARM: support for Moschip MCS814x SoCs
ARM: MCS814x: add Device Tree based MCS8140 board support
ARM: MCS814x: add Device Tree bindings documentation
ARM: MCS814X: add DTS file for Tigal/Robotech RBT-832
ARM: MCS814x: add DTS file for Devolo dLAN USB Extender
ARM: MCS814x: provide a sample defconfig file
ARM: MSC814X: add Kconfig and Makefile to arch/arm
ARM: MSC814x: add MAINTAINERS entry
.../bindings/arm/mcs814x/mcs814x-intc.txt | 18 + .../bindings/arm/mcs814x/mcs814x-pci.txt | 16 + .../bindings/arm/mcs814x/mcs814x-timer.txt | 16 + .../devicetree/bindings/arm/mcs814x/mcs814x.txt | 13 + .../devicetree/bindings/vendor-prefixes.txt | 1 + MAINTAINERS | 6 + arch/arm/Kconfig | 28 ++ arch/arm/Makefile | 1 + arch/arm/boot/dts/dlan-usb-extender.dts | 68 +++ arch/arm/boot/dts/mcs8140.dtsi | 207 +++++++++ arch/arm/boot/dts/rbt-832.dts | 83 ++++ arch/arm/configs/mcs814x_defconfig | 174 ++++++++ arch/arm/mach-mcs814x/Kconfig | 29 ++ arch/arm/mach-mcs814x/Makefile | 6 + arch/arm/mach-mcs814x/Makefile.boot | 6 + arch/arm/mach-mcs814x/board-mcs8140-dt.c | 46 ++ arch/arm/mach-mcs814x/clock.c | 271 ++++++++++++ arch/arm/mach-mcs814x/common.c | 97 +++++ arch/arm/mach-mcs814x/common.h | 15 + arch/arm/mach-mcs814x/include/mach/cpu.h | 16 + arch/arm/mach-mcs814x/include/mach/debug-macro.S | 11 + arch/arm/mach-mcs814x/include/mach/entry-macro.S | 29 ++ arch/arm/mach-mcs814x/include/mach/gpio.h | 1 + arch/arm/mach-mcs814x/include/mach/hardware.h | 16 + arch/arm/mach-mcs814x/include/mach/irqs.h | 22 + arch/arm/mach-mcs814x/include/mach/mcs814x.h | 53 +++ arch/arm/mach-mcs814x/include/mach/memory.h | 16 + arch/arm/mach-mcs814x/include/mach/timex.h | 18 + arch/arm/mach-mcs814x/include/mach/uncompress.h | 41 ++ arch/arm/mach-mcs814x/irq.c | 69 +++ arch/arm/mach-mcs814x/pci.c | 446 ++++++++++++++++++++ arch/arm/mach-mcs814x/timer.c | 133 ++++++ 32 files changed, 1972 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/mcs814x/mcs814x-intc.txt create mode 100644 Documentation/devicetree/bindings/arm/mcs814x/mcs814x-pci.txt create mode 100644 Documentation/devicetree/bindings/arm/mcs814x/mcs814x-timer.txt create mode 100644 Documentation/devicetree/bindings/arm/mcs814x/mcs814x.txt create mode 100644 arch/arm/boot/dts/dlan-usb-extender.dts create mode 100644 arch/arm/boot/dts/mcs8140.dtsi create mode 100644 arch/arm/boot/dts/rbt-832.dts create mode 100644 arch/arm/configs/mcs814x_defconfig create mode 100644 arch/arm/mach-mcs814x/Kconfig create mode 100644 arch/arm/mach-mcs814x/Makefile create mode 100644 arch/arm/mach-mcs814x/Makefile.boot create mode 100644 arch/arm/mach-mcs814x/board-mcs8140-dt.c create mode 100644 arch/arm/mach-mcs814x/clock.c create mode 100644 arch/arm/mach-mcs814x/common.c create mode 100644 arch/arm/mach-mcs814x/common.h create mode 100644 arch/arm/mach-mcs814x/include/mach/cpu.h create mode 100644 arch/arm/mach-mcs814x/include/mach/debug-macro.S create mode 100644 arch/arm/mach-mcs814x/include/mach/entry-macro.S create mode 100644 arch/arm/mach-mcs814x/include/mach/gpio.h create mode 100644 arch/arm/mach-mcs814x/include/mach/hardware.h create mode 100644 arch/arm/mach-mcs814x/include/mach/irqs.h create mode 100644 arch/arm/mach-mcs814x/include/mach/mcs814x.h create mode 100644 arch/arm/mach-mcs814x/include/mach/memory.h create mode 100644 arch/arm/mach-mcs814x/include/mach/timex.h create mode 100644 arch/arm/mach-mcs814x/include/mach/uncompress.h create mode 100644 arch/arm/mach-mcs814x/irq.c create mode 100644 arch/arm/mach-mcs814x/pci.c create mode 100644 arch/arm/mach-mcs814x/timer.c
Signature · 1 line
1.7.10.4
PATCH 1/8 ARM: support for Moschip MCS814x SoCs
This patch adds support for Moschip's MCS814x SoCs, and in particular MCS8140. This SoC has the following characteristics:
- uses an ARM926EJS CPU core with an AHB/VCI64 interconnect
- simple clocking scheme and clock gating
- strap registers defining CPU, SDRAM and Timer frequency
- various on-chip peripherals:
* 2x OHCI controller
* 1x EHCI controller
* IPsec unit
* Watchdog
* Random number generator
* 10/100 Ethernet MAC w/ TCP offloading and checksumming
* I2S
* 4 + 20 GPIOs
* PCI master interface
--- arch/arm/mach-mcs814x/Kconfig | 11 + arch/arm/mach-mcs814x/Makefile | 6 + arch/arm/mach-mcs814x/Makefile.boot | 3 + arch/arm/mach-mcs814x/clock.c | 271 +++++++++++++ arch/arm/mach-mcs814x/common.c | 97 +++++ arch/arm/mach-mcs814x/common.h | 15 + arch/arm/mach-mcs814x/include/mach/cpu.h | 16 + arch/arm/mach-mcs814x/include/mach/debug-macro.S | 11 + arch/arm/mach-mcs814x/include/mach/entry-macro.S | 29 ++ arch/arm/mach-mcs814x/include/mach/gpio.h | 1 + arch/arm/mach-mcs814x/include/mach/hardware.h | 16 + arch/arm/mach-mcs814x/include/mach/irqs.h | 22 ++ arch/arm/mach-mcs814x/include/mach/mcs814x.h | 53 +++ arch/arm/mach-mcs814x/include/mach/memory.h | 16 + arch/arm/mach-mcs814x/include/mach/timex.h | 18 + arch/arm/mach-mcs814x/include/mach/uncompress.h | 41 ++ arch/arm/mach-mcs814x/irq.c | 69 ++++ arch/arm/mach-mcs814x/pci.c | 446 ++++++++++++++++++++++ arch/arm/mach-mcs814x/timer.c | 133 +++++++ 19 files changed, 1274 insertions(+) create mode 100644 arch/arm/mach-mcs814x/Kconfig create mode 100644 arch/arm/mach-mcs814x/Makefile create mode 100644 arch/arm/mach-mcs814x/Makefile.boot create mode 100644 arch/arm/mach-mcs814x/clock.c create mode 100644 arch/arm/mach-mcs814x/common.c create mode 100644 arch/arm/mach-mcs814x/common.h create mode 100644 arch/arm/mach-mcs814x/include/mach/cpu.h create mode 100644 arch/arm/mach-mcs814x/include/mach/debug-macro.S create mode 100644 arch/arm/mach-mcs814x/include/mach/entry-macro.S create mode 100644 arch/arm/mach-mcs814x/include/mach/gpio.h create mode 100644 arch/arm/mach-mcs814x/include/mach/hardware.h create mode 100644 arch/arm/mach-mcs814x/include/mach/irqs.h create mode 100644 arch/arm/mach-mcs814x/include/mach/mcs814x.h create mode 100644 arch/arm/mach-mcs814x/include/mach/memory.h create mode 100644 arch/arm/mach-mcs814x/include/mach/timex.h create mode 100644 arch/arm/mach-mcs814x/include/mach/uncompress.h create mode 100644 arch/arm/mach-mcs814x/irq.c create mode 100644 arch/arm/mach-mcs814x/pci.c create mode 100644 arch/arm/mach-mcs814x/timer.c
arch/arm/mach-mcs814x/Kconfig new file +11 -0
@@ -0,0 +1,11 @@ +if ARCH_MCS814X + +config MCS8140 + select CPU_ARM926T + bool + +menu "Moschip MCS8140 boards" + +endmenu + +endif
arch/arm/mach-mcs814x/Makefile new file +6 -0
@@ -0,0 +1,6 @@ +obj-y += clock.o +obj-y += common.o +obj-y += irq.o +obj-y += timer.o +obj-y += board-mcs8140-dt.o +obj-$(CONFIG_PCI) += pci.o
arch/arm/mach-mcs814x/Makefile.boot new file +3 -0
@@ -0,0 +1,3 @@ + zreladdr-y := 0x00008000 + params_phys-y := 0x00000008 + initrd_phys-y := 0x00400000
arch/arm/mach-mcs814x/clock.c new file +271 -0
271 lines not on this page · raw message
arch/arm/mach-mcs814x/common.c new file +97 -0
97 lines not on this page · raw message
arch/arm/mach-mcs814x/common.h new file +15 -0
@@ -0,0 +1,15 @@ +#ifndef __ARCH_MCS814X_COMMON_H +#define __ARCH_MCS814X_COMMON_H + +#include <asm/mach/time.h> + +void mcs814x_map_io (void ); +void mcs814x_clk_init (void ); +void mcs814x_of_irq_init (void ); +void mcs814x_init_machine (void ); +void mcs814x_handle_irq (struct pt_regs *regs); +void mcs814x_restart (char mode,const char *cmd); +extern struct sys_timer mcs814x_timer; +extern void __iomem *mcs814x_sysdbg_base; + +#endif /* __ARCH_MCS814X_COMMON_H */
arch/arm/mach-mcs814x/include/mach/cpu.h new file +16 -0
@@ -0,0 +1,16 @@ +#ifndef __ASM_ARCH_CPU_H__ +#define __ASM_ARCH_CPU_H__ + +#include <asm/cputype.h> + +#define MCS8140_ID 0x41069260/* ARM926EJ-S */ +#define MCS814X_MASK 0xff0ffff0 + +#ifdef CONFIG_MCS8140 +/* Moschip MCS8140 is based on an ARM926EJ-S core */ +#define soc_is_mcs8140 () ((read_cpuid_id() & MCS814X_MASK) == MCS8140_ID) +#else +#define soc_is_mcs8140 () (0) +#endif /* !CONFIG_MCS8140 */ + +#endif /* __ASM_ARCH_CPU_H__ */
arch/arm/mach-mcs814x/include/mach/debug-macro.S new file +11 -0
@@ -0,0 +1,11 @@ +#include <mach/mcs814x.h> + + .macro addruart, rp, rv, tmp + ldr \rp, =MCS814X_PHYS_BASE + ldr \rv, =MCS814X_VIRT_BASE + orr \rp, \rp, #MCS814X_UART + orr \rv, \rv, #MCS814X_UART + .endm + +#define UART_SHIFT 2 +#include <asm/hardware/debug-8250.S>
arch/arm/mach-mcs814x/include/mach/entry-macro.S new file +29 -0
@@ -0,0 +1,29 @@ +#include <mach/mcs814x.h> + .macro disable_fiq + .endm + + .macro arch_ret_to_user, tmp1, tmp2 + .endm + + .macro get_irqnr_preamble, base, tmp + ldr \base, =mcs814x_intc_base@ base virtual address of INTC + ldr \base, [\base] + .endm + + .macro get_irqnr_and_base, irqnr, irqstat, base, tmp + mov \tmp, #MCS814X_IRQ_STS0 @ load tmp with STS0 register offset + ldr \irqstat, [\base, \tmp] @ load value at base + tmp + tst \irqstat, \irqstat @ test if no active IRQ's + beq 1002f @ if no active irqs return with status 0 + mov \irqnr, #0 @ start from irq zero + mov \tmp, #1 @ the mask initially 1 +1001: + tst \irqstat, \tmp @ and with mask + addeq \irqnr, \irqnr, #1 @ if zero then add one to nr + moveq \tmp, \tmp, lsl #1 @ shift mask one to left + beq 1001b @ if zero then loop again + mov \irqstat, \tmp @ save the return mask + mov \tmp, #MCS814X_IRQ_STS0 @ load tmp with ICR offset + str \irqstat, [\base, \tmp] @ clear irq with selected mask +1002: + .endm
arch/arm/mach-mcs814x/include/mach/gpio.h new file +1 -0
@@ -0,0 +1 @@ +/* empty */
arch/arm/mach-mcs814x/include/mach/hardware.h new file +16 -0
@@ -0,0 +1,16 @@ +/* +* Copyright (C) 2003 Artec Design Ltd. +* +* 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 "mcs814x.h" + +#endif +
arch/arm/mach-mcs814x/include/mach/irqs.h new file +22 -0
@@ -0,0 +1,22 @@ +/* +* Copyright (C) 2003 Artec Design Ltd. +* +* 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_IRQS_H +#define __ASM_ARCH_IRQS_H + +#define FIQ_START 0 + +#define NR_IRQS 32 + +#define IRQ_PCI_INTA 22 +#define IRQ_PCI_INTB 23 +#define IRQ_PCI_INTC 24 +#define IRQ_PCI_INTD 26 + +#endif
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +53 -0
53 lines not on this page · raw message
arch/arm/mach-mcs814x/include/mach/memory.h new file +16 -0
@@ -0,0 +1,16 @@ +/* +* Copyright (C) 2003 Artec Design Ltd. +* Copyright (C) 2012, Florian Fainelli <[email protected]> +* +* 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_MEMORY_H +#define __ASM_ARCH_MEMORY_H + +#define PLAT_PHYS_OFFSET UL(0x00000000) + +#endif
arch/arm/mach-mcs814x/include/mach/timex.h new file +18 -0
@@ -0,0 +1,18 @@ +/* +* Copyright (C) 2003 Artec Design Ltd. +* +* 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_TIMEX_H +#define __ASM_ARCH_TIMEX_H + +/* +* Timex specification for MCS814X +*/ +#define CLOCK_TICK_RATE 100 + +#endif
arch/arm/mach-mcs814x/include/mach/uncompress.h new file +41 -0
41 lines not on this page · raw message
arch/arm/mach-mcs814x/irq.c new file +69 -0
69 lines not on this page · raw message
arch/arm/mach-mcs814x/pci.c new file +446 -0
446 lines not on this page · raw message
arch/arm/mach-mcs814x/timer.c new file +133 -0
133 lines not on this page · raw message
Signature · 1 line
1.7.10.4
PATCH 1/8 ARM: support for Moschip MCS814x SoCs
Hello Florian,
Le Sun, 15 Jul 2012 16:49:07 +0200,
Florian Fainelli <[email protected]> a ?crit :
arch/arm/mach-mcs814x/Makefile.boot line 3
Quoted 9 lines
arch/arm/mach-mcs814x/Makefile.boot new file +3
-0@@ -0,0 +1,3 @@ + zreladdr-y := 0x00008000 + params_phys-y := 0x00000008 + initrd_phys-y := 0x00400000
params_phys-y and initrd_phys-y are useless for DT-based platforms, if I'm correct.
Quoted 243 lines
arch/arm/mach-mcs814x/clock.c new file +237
-0@@ -0,0 +1,271 @@ +/* +* Moschip MCS814x clock routines +* +* Copyright (C) 2012, Florian Fainelli <[email protected]> +* +* Licensed under GPLv2 +*/ +#include <linux/kernel.h> +#include <linux/init.h> +#include <linux/export.h> +#include <linux/spinlock.h> +#include <linux/err.h> +#include <linux/io.h> +#include <linux/clkdev.h> +#include <linux/clk.h> + +#include <mach/mcs814x.h> + +#include "common.h" + +#define KHZ 1000 +#define MHZ (KHZ * KHZ) + +struct clk_ops { +unsigned long (*get_rate)(struct clk *clk); +int (*set_rate)(struct clk *clk,unsigned long rate); +struct clk *(*get_parent)(struct clk *clk); +int (*enable)(struct clk *clk,int enable); +}; + +struct clk { +struct clk *parent;/* parent clk */ +unsigned long rate;/* clock rate in Hz */ +unsigned long divider;/* clock divider */ +u32 usecount;/* reference count */ +struct clk_ops *ops;/* clock operation */ +u32 enable_reg;/* clock enable register */ +u32 enable_mask;/* clock enable mask */ +}; + +static unsigned long clk_divide_parent (struct clk *clk) +{ +if (clk->parent && clk->divider) +return clk_get_rate (clk->parent) / clk->divider; +else +return 0 ; +} + +static int clk_local_onoff_enable (struct clk *clk,int enable) +{ +u32 tmp; + +/* no enable_reg means the clock is always enabled */ +if (!clk->enable_reg) +return 0 ; + + tmp =__raw_readl (mcs814x_sysdbg_base + clk->enable_reg); +if (!enable) + tmp &= ~clk->enable_mask; +else + tmp |= clk->enable_mask; + +__raw_writel (tmp, mcs814x_sysdbg_base + clk->enable_reg); + +return 0 ; +} + +static struct clk_ops default_clk_ops = { + .get_rate = clk_divide_parent, + .enable = clk_local_onoff_enable, +}; + +static DEFINE_SPINLOCK (clocks_lock); + +static const unsigned long cpu_freq_table[] = { +175000 , +300000 , +125000 , +137500 , +212500 , +250000 , +162500 , +187500 , +162500 , +150000 , +225000 , +237500 , +200000 , +262500 , +275000 , +287500 +}; + +static struct clk clk_cpu; + +/* System clock is fixed at 50Mhz */ +static struct clk clk_sys = { + .rate =50 *MHZ , +}; + +static struct clk clk_sdram; + +static struct clk clk_timer0 = { + .parent = &clk_sdram, + .divider =2 , + .ops = &default_clk_ops, +}; + +static struct clk clk_timer1_2 = { + .parent = &clk_sys, +}; + +/* Watchdog clock is system clock / 128 */ +static struct clk clk_wdt = { + .parent = &clk_sys, + .divider =128 , + .ops = &default_clk_ops, +}; + +static struct clk clk_emac = { + .ops = &default_clk_ops, + .enable_reg =SYSDBG_SYSCTL , + .enable_mask =SYSCTL_EMAC , +}; + +static struct clk clk_ephy = { + .ops = &default_clk_ops, + .enable_reg =SYSDBG_PLL_CTL , + .enable_mask = ~SYSCTL_EPHY ,/* active low */ +}; + +static struct clk clk_cipher = { + .ops = &default_clk_ops, + .enable_reg =SYSDBG_SYSCTL , + .enable_mask =SYSCTL_CIPHER , +}; + +#define CLK (_dev, _con, _clk) \ +{ .dev_id = (_dev), .con_id = (_con), .clk = (_clk) }, + +static struct clk_lookup mcs814x_chip_clks[] = { + CLK("cpu", NULL, &clk_cpu) + CLK("sys", NULL, &clk_sys) + CLK("sdram", NULL, &clk_sdram) +/* 32-bits timer0 */ + CLK("timer0", NULL, &clk_timer0) +/* 16-bits timer1 */ + CLK("timer1", NULL, &clk_timer1_2) +/* 64-bits timer2, same as timer 1 */ + CLK("timer2", NULL, &clk_timer1_2) + CLK(NULL, "wdt", &clk_wdt) + CLK(NULL, "emac", &clk_emac) + CLK(NULL, "ephy", &clk_ephy) +CLK (NULL ,"cipher" , &clk_cipher) +}; + +static void local_clk_disable (struct clk *clk) +{ +WARN_ON (!clk->usecount); + +if (clk->usecount >0 ) { + clk->usecount--; + +if ((clk->usecount ==0 ) && (clk->ops->enable)) + clk->ops->enable (clk,0 ); + +if (clk->parent) +local_clk_disable (clk->parent); + } +} + +static int local_clk_enable (struct clk *clk) +{ +int ret =0 ; + +if (clk->parent) + ret =local_clk_enable (clk->parent); + +if (ret) +return ret; + +if ((clk->usecount ==0 ) && (clk->ops->enable)) + ret = clk->ops->enable (clk,1 ); + +if (!ret) + clk->usecount++; +else if (clk->parent && clk->parent->ops->enable) +local_clk_disable (clk->parent); + +return ret; +} + +int clk_enable (struct clk *clk) +{ +int ret; +unsigned long flags; + +spin_lock_irqsave (&clocks_lock, flags); + ret =local_clk_enable (clk); +spin_unlock_irqrestore (&clocks_lock, flags); + +return ret; +} +EXPORT_SYMBOL (clk_enable); + +void clk_disable (struct clk *clk) +{ +unsigned long flags; + +spin_lock_irqsave (&clocks_lock, flags); +local_clk_disable (clk); +spin_unlock_irqrestore (&clocks_lock, flags); +} +EXPORT_SYMBOL (clk_disable); + +unsigned long clk_get_rate (struct clk *clk) +{ +if (unlikely (IS_ERR_OR_NULL (clk))) +return 0 ; + +if (clk->rate) +return clk->rate; + +if (clk->ops && clk->ops->get_rate) +return clk->ops->get_rate (clk); + +return clk_get_rate (clk->parent); +} +EXPORT_SYMBOL (clk_get_rate); + +struct clk *clk_get_parent (struct clk *clk) +{ +unsigned long flags; + +if (unlikely (IS_ERR_OR_NULL (clk))) +return NULL ; +
arch/arm/mach-mcs814x/clock.c line 247
Quoted 10 lines
arch/arm/mach-mcs814x/clock.c new file +10
-0+if (!clk->ops || !clk->ops->get_parent) +return clk->parent; + +spin_lock_irqsave (&clocks_lock, flags); + clk->parent = clk->ops->get_parent (clk); +spin_unlock_irqrestore (&clocks_lock, flags); + +return clk->parent; +} +EXPORT_SYMBOL (clk_get_parent);
You should rather use the new clock framework instead of providing your own implementation of the clk_*() API. And therefore your clock driver should be in drivers/clk/ instead.
Quoted 34 lines
arch/arm/mach-mcs814x/clock.c new file +34
-0+struct cpu_mode { +const char *name; +int gpio_start; +int gpio_end; +}; + +static const struct cpu_mode cpu_modes[] = { + { + .name ="I2S" , + .gpio_start =4 , + .gpio_end =8 , + }, + { + .name ="UART" , + .gpio_start =4 , + .gpio_end =9 , + }, + { + .name ="External MII" , + .gpio_start =0 , + .gpio_end =16 , + }, + { + .name ="Normal" , + .gpio_start =-1 , + .gpio_end =-1 , + }, +}; + +void __init mcs814x_init_machine (void ) +{ +u32 bs2, cpu_mode; +int gpio; +
arch/arm/mach-mcs814x/clock.c
Quoted 10 lines
arch/arm/mach-mcs814x/clock.c new file +10
-0+ bs2 =__raw_readl (mcs814x_sysdbg_base +SYSDBG_BS2 ); + cpu_mode = (bs2 >>CPU_MODE_SHIFT ) &CPU_MODE_MASK ; + +pr_info ("CPU mode: %s\n" , cpu_modes[cpu_mode].name); + +/* request the gpios since the pins are muxed for functionnality */ +for (gpio = cpu_modes[cpu_mode].gpio_start; + gpio == cpu_modes[cpu_mode].gpio_end; gpio++) { +if (gpio !=-1 ) +gpio_request (gpio, cpu_modes[cpu_mode].name);
I am not sure here, but shouldn't this be done with the pinctrl subsystem instead?
arch/arm/mach-mcs814x/clock.c
Quoted 8 lines
arch/arm/mach-mcs814x/clock.c new file +8
-0+void __init mcs814x_map_io (void ) +{ +iotable_init (mcs814x_io_desc,ARRAY_SIZE (mcs814x_io_desc)); + + mcs814x_sysdbg_base =ioremap (MCS814X_IO_START +MCS814X_SYSDBG , +MCS814X_SYSDBG_SIZE ); +if (!mcs814x_sysdbg_base) +panic ("unable to remap sysdbg base" );
Any reason to have a static mapping initialized with iotable_init() and then a dynamic mapping initialized with ioremap() ? I thought that ioremap() wasn't ready at the ->map_io() time, and it was therefore the reason we had static mappings.
Quoted 25 lines
arch/arm/mach-mcs814x/include/mach/entry-macro.S new file +19
-0@@ -0,0 +1,29 @@ +#include <mach/mcs814x.h> + .macro disable_fiq + .endm + + .macro arch_ret_to_user, tmp1, tmp2 + .endm + + .macro get_irqnr_preamble, base, tmp + ldr \base, =mcs814x_intc_base@ base virtual address of INTC + ldr \base, [\base] + .endm + + .macro get_irqnr_and_base, irqnr, irqstat, base, tmp + mov \tmp, #MCS814X_IRQ_STS0 @ load tmp with STS0 register offset + ldr \irqstat, [\base, \tmp] @ load value at base + tmp + tst \irqstat, \irqstat @ test if no active IRQ's + beq 1002f @ if no active irqs return with status 0 + mov \irqnr, #0 @ start from irq zero + mov \tmp, #1 @ the mask initially 1
arch/arm/mach-mcs814x/include/mach/entry-macro.S line 29
Quoted 10 lines
arch/arm/mach-mcs814x/include/mach/entry-macro.S new file +10
-0+1001: + tst \irqstat, \tmp @ and with mask + addeq \irqnr, \irqnr, #1 @ if zero then add one to nr + moveq \tmp, \tmp, lsl #1 @ shift mask one to left + beq 1001b @ if zero then loop again + mov \irqstat, \tmp @ save the return mask + mov \tmp, #MCS814X_IRQ_STS0 @ load tmp with ICR offset + str \irqstat, [\base, \tmp] @ clear irq with selected mask +1002: + .endm
Hum, you should instead use the MULTI_IRQ_HANDLER feature so that this can be written in C.
Quoted 7 lines
arch/arm/mach-mcs814x/include/mach/hardware.h new file +1
-0@@ -0,0 +1,16 @@ +/*
arch/arm/mach-mcs814x/include/mach/hardware.h line 11
Quoted 10 lines
arch/arm/mach-mcs814x/include/mach/hardware.h new file +10
-0+* Copyright (C) 2003 Artec Design Ltd. +* +* 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
This #define name no longer looks consistent with where the file is located.
Quoted 15 lines
arch/arm/mach-mcs814x/include/mach/hardware.h new file +4
-0+#include "mcs814x.h" + +#endif +arch/arm/mach-mcs814x/include/mach/irqs.h new file +5
-0@@ -0,0 +1,22 @@ +/* +* Copyright (C) 2003 Artec Design Ltd. +* +* 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
arch/arm/mach-mcs814x/include/mach/irqs.h line 15
Quoted 10 lines
arch/arm/mach-mcs814x/include/mach/irqs.h new file +10
-0+* published by the Free Software Foundation. +* +*/ + +#ifndef __ASM_ARCH_IRQS_H +#define __ASM_ARCH_IRQS_H + +#define FIQ_START 0 + +#define NR_IRQS 32
I think this shouldn't be needed if you use SPARSE_IRQ support.
arch/arm/mach-mcs814x/include/mach/irqs.h line 20
Quoted 4 lines
arch/arm/mach-mcs814x/include/mach/irqs.h new file +4
-0+#define IRQ_PCI_INTA 22 +#define IRQ_PCI_INTB 23 +#define IRQ_PCI_INTC 24 +#define IRQ_PCI_INTD 26
And these probably belong to the DT somehow?
Quoted 129 lines
arch/arm/mach-mcs814x/timer.c new file +123
-0@@ -0,0 +1,133 @@ +/* +* Moschip MCS814x timer routines +* +* Copyright (C) 2012, Florian Fainelli <[email protected]> +* +* Licensed under GPLv2 +*/ +#include <linux/kernel.h> +#include <linux/interrupt.h> +#include <linux/time.h> +#include <linux/timex.h> +#include <linux/irq.h> +#include <linux/err.h> +#include <linux/clk.h> +#include <linux/io.h> +#include <linux/of.h> +#include <linux/of_address.h> + +#include <asm/mach/time.h> +#include <mach/mcs814x.h> + +/* Timer block registers */ +#define TIMER_VAL 0x00 +#define TIMER_CTL 0x04 + +static u32 last_reload; +static u32 timer_correct; +static u32 clock_rate; +static u32 timer_reload_value; +static void __iomem *mcs814x_timer_base; + +static inline unsigned long ticks2usecs (u32 x) +{ +return x / (clock_rate /1000000 ); +} + +/* +* Returns number of ms since last clock interrupt. Note that interrupts +* will have been disabled by do_gettimeoffset() +*/ +static unsigned long mcs814x_gettimeoffset (void ) +{ +u32 ticks =__raw_readl (mcs814x_timer_base +TIMER_VAL ); + +if (ticks < last_reload) +return ticks2usecs (ticks + (u32)(0xffffffff - last_reload)); +else +return ticks2usecs (ticks - last_reload); +} + + +static irqreturn_t mcs814x_timer_interrupt (int irq,void *dev_id) +{ +u32 count =__raw_readl (mcs814x_timer_base +TIMER_VAL ); + +/* take into account delay up to this moment */ + last_reload = count + timer_correct + timer_reload_value; + +if (last_reload < timer_reload_value) + last_reload = timer_reload_value; +else if (timer_correct ==0 ) + timer_correct =__raw_readl (mcs814x_timer_base +TIMER_VAL ) - + count; + +__raw_writel (last_reload, mcs814x_timer_base +TIMER_VAL ); + +timer_tick (); + +return IRQ_HANDLED ; +} + +static struct irqaction mcs814x_timer_irq = { + .name ="mcs814x-timer" , + .flags =IRQF_DISABLED |IRQF_TIMER |IRQF_IRQPOLL , + .handler = mcs814x_timer_interrupt, +}; + +static struct of_device_id mcs814x_timer_ids[] = { + { .compatible ="moschip,mcs814x-timer" }, + {/* sentinel */ }, +}; + +static void __init mcs814x_of_timer_init (void ) +{ +struct device_node *np; +const unsigned int *intspec; + + np =of_find_matching_node (NULL , mcs814x_timer_ids); +if (!np) +panic ("unable to find compatible timer node in dtb" ); + + mcs814x_timer_base =of_iomap (np,0 ); +if (!mcs814x_timer_base) +panic ("unable to remap timer cpu registers" ); + + intspec =of_get_property (np,"interrupts" ,NULL ); +if (!intspec) +panic ("no interrupts property for timer" ); + + mcs814x_timer_irq.irq =be32_to_cpup (intspec); +} + +static void __init mcs814x_timer_init (void ) +{ +struct clk *clk; + + clk =clk_get_sys ("timer0" ,NULL ); +if (IS_ERR_OR_NULL (clk)) +panic ("unable to get timer0 clock" ); + + clock_rate =clk_get_rate (clk); +clk_put (clk); + +mcs814x_of_timer_init (); + +pr_info ("Timer frequency: %d (kHz)\n" , clock_rate /1000 ); + + timer_reload_value =0xffffffff - (clock_rate /HZ ); + +/* disable timer */ +__raw_writel (0 , mcs814x_timer_base +TIMER_CTL ); +__raw_writel (timer_reload_value, mcs814x_timer_base +TIMER_VAL ); + last_reload = timer_reload_value;
arch/arm/mach-mcs814x/timer.c line 133
Quoted 10 lines
arch/arm/mach-mcs814x/timer.c new file +10
-0+ +setup_irq (mcs814x_timer_irq.irq, &mcs814x_timer_irq); +/* enable timer, stop timer in debug mode */ +__raw_writel (0x03 , mcs814x_timer_base +TIMER_CTL ); +} + +struct sys_timer mcs814x_timer = { + .init = mcs814x_timer_init, + .offset = mcs814x_gettimeoffset, +};
I am surprised that this doesn't use the clocksource and clockevents infrastructure. It probably should, and be implemented in drivers/clocksource/.
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 1/8 ARM: support for Moschip MCS814x SoCs
Hi Thomas,
Quoted 6 lines · On Monday 16 July 2012 14:29:41 Thomas Petazzoni wrote:
Hello Florian,
Le Sun, 15 Jul 2012 16:49:07 +0200,
Florian Fainelli <[email protected]> a ?crit :arch/arm/mach-
Quoted 1 line
arch/arm/mach- renamed from arch/arm/mach-mcs814x/Makefile.boot +0
-0
mcs814x/Makefile.boot
Quoted 11 lines
arch/arm/mach-mcs814x/Makefile.boot line 3
Quoted 8 lines
new file mode 100644
index 0000000..414db8barch/arm/mach-mcs814x/Makefile.boot new file +3
-0@@ -0,0 +1,3 @@ + zreladdr-y := 0x00008000 + params_phys-y := 0x00000008 + initrd_phys-y := 0x00400000params_phys-y and initrd_phys-y are useless for DT-based platforms, if I'm correct.
Indeed, only zreladdr is actually required.
Quoted 6 lines
Quoted 6 lines
arch/arm/mach-mcs814x/clock.c new file +0
-0
[snip]
Quoted 4 lines
You should rather use the new clock framework instead of providing your own implementation of the clk_*() API. And therefore your clock driver should be in
drivers/clk/instead.
Since I was targetting 3.6 initially I more or less used what was existing by the time I wrote the patches, but I will do this.
Quoted 40 lines
Quoted 40 lines
arch/arm/mach-mcs814x/clock.c new file +39
-0+struct cpu_mode { +const char *name; +int gpio_start; +int gpio_end; +}; + +static const struct cpu_mode cpu_modes[] = { + { + .name ="I2S" , + .gpio_start =4 , + .gpio_end =8 , + }, + { + .name ="UART" , + .gpio_start =4 , + .gpio_end =9 , + }, + { + .name ="External MII" , + .gpio_start =0 , + .gpio_end =16 , + }, + { + .name ="Normal" , + .gpio_start =-1 , + .gpio_end =-1 , + }, +}; + +void __init mcs814x_init_machine (void ) +{ +u32 bs2, cpu_mode; +int gpio; + + bs2 =__raw_readl (mcs814x_sysdbg_base +SYSDBG_BS2 ); + cpu_mode = (bs2 >>CPU_MODE_SHIFT ) &CPU_MODE_MASK ; + +pr_info ("CPU mode: %s\n" , cpu_modes[cpu_mode].name); +
Quoted 8 lines
arch/arm/mach-mcs814x/clock.c
Quoted 5 lines
arch/arm/mach-mcs814x/clock.c new file +5
-0+/* request the gpios since the pins are muxed for functionnality */ +for (gpio = cpu_modes[cpu_mode].gpio_start; + gpio == cpu_modes[cpu_mode].gpio_end; gpio++) { +if (gpio !=-1 ) +gpio_request (gpio, cpu_modes[cpu_mode].name);I am not sure here, but shouldn't this be done with the pinctrl subsystem instead?
This muxing is actually hardwired with the bootstrap register setting. I could also even remove this because the underlying hardware block actually does not need to use the GPIOs, they will be configured as pins for the corresponding functions directly. This is also not runtime modifiable. I just thought that marking these GPIOs as reserved by the corresponding functionnality could help the user figuring out what is happening with them.
Quoted 14 lines
arch/arm/mach-mcs814x/clock.c
Quoted 9 lines
arch/arm/mach-mcs814x/clock.c new file +8
-0+void __init mcs814x_map_io (void ) +{ +iotable_init (mcs814x_io_desc,ARRAY_SIZE (mcs814x_io_desc)); + + mcs814x_sysdbg_base =ioremap (MCS814X_IO_START +MCS814X_SYSDBG , +MCS814X_SYSDBG_SIZE ); +if (!mcs814x_sysdbg_base) +panic ("unable to remap sysdbg base" );Any reason to have a static mapping initialized with
iotable_init()and then a dynamic mapping initialized withioremap()? I thought thatioremap()wasn't ready at the ->map_io() time, and it was therefore the reason we had static mappings.
There are no particular reasons, I could use the the define for the virtual address directly.
Quoted 2 lines
Review
Quoted 2 lines
(quoted diff) +0
-0
b/arch/arm/mach-mcs814x/include/mach/entry-macro.S
Quoted 11 lines
Quoted 11 lines
new file mode 100644
index 0000000..cbad566arch/arm/mach-mcs814x/include/mach/entry-macro.S new file +6
-0@@ -0,0 +1,29 @@ +#include <mach/mcs814x.h> + .macro disable_fiq + .endm + + .macro arch_ret_to_user, tmp1, tmp2 + .endm
Quoted 8 lines
arch/arm/mach-mcs814x/include/mach/entry-macro.S
Quoted 8 lines
arch/arm/mach-mcs814x/include/mach/entry-macro.S new file +8
-0+ + .macro get_irqnr_preamble, base, tmp + ldr \base, =mcs814x_intc_base@ base virtual address of INTC + ldr \base, [\base] + .endm + + .macro get_irqnr_and_base, irqnr, irqstat, base, tmp + mov \tmp, #MCS814X_IRQ_STS0 @ load tmp with STS0 register
offset
Quoted 3 lines
arch/arm/mach-mcs814x/include/mach/entry-macro.S
Quoted 3 lines
arch/arm/mach-mcs814x/include/mach/entry-macro.S new file +3
-0+ ldr \irqstat, [\base, \tmp] @ load value at base + tmp + tst \irqstat, \irqstat @ test if no active IRQ's + beq 1002f @ if no active irqs return with
status 0
Quoted 10 lines
arch/arm/mach-mcs814x/include/mach/entry-macro.S
Quoted 10 lines
arch/arm/mach-mcs814x/include/mach/entry-macro.S new file +10
-0+ mov \irqnr, #0 @ start from irq zero + mov \tmp, #1 @ the mask initially 1 +1001: + tst \irqstat, \tmp @ and with mask + addeq \irqnr, \irqnr, #1 @ if zero then add one to nr + moveq \tmp, \tmp, lsl #1 @ shift mask one to left + beq 1001b @ if zero then loop again + mov \irqstat, \tmp @ save the return mask + mov \tmp, #MCS814X_IRQ_STS0 @ load tmp with ICR offset + str \irqstat, [\base, \tmp] @ clear irq with selected
mask
Quoted 5 lines
arch/arm/mach-mcs814x/include/mach/entry-macro.S line 29
Quoted 2 lines
arch/arm/mach-mcs814x/include/mach/entry-macro.S new file +2
-0+1002: + .endmHum, you should instead use the
MULTI_IRQ_HANDLERfeature so that this can be written in C.
Last I did this, I managed to get interrupt handling issues with Ethernet, but I will try to address this. So far, since we support only MCS8140 this is not a problem, MCS8142 also has the same interrupt controller.
Quoted 2 lines
arch/arm/mach-
Quoted 2 lines
arch/arm/mach- renamed from arch/arm/mach-mcs814x/include/mach/hardware.h +0
-0
mcs814x/include/mach/hardware.h
Quoted 11 lines
Quoted 11 lines
new file mode 100644
index 0000000..529f648arch/arm/mach-mcs814x/include/mach/hardware.h new file +6
-0@@ -0,0 +1,16 @@ +/* +* Copyright (C) 2003 Artec Design Ltd. +* +* 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.
Quoted 8 lines
arch/arm/mach-mcs814x/include/mach/hardware.h line 11
Quoted 5 lines
arch/arm/mach-mcs814x/include/mach/hardware.h new file +5
-0+* +*/ + +#ifndef __ASM_ARCH_HARDWARE_H +#define __ASM_ARCH_HARDWARE_HThis #define name no longer looks consistent with where the file is located.
Right, thanks!
Quoted 6 lines
arch/arm/mach-
Quoted 6 lines
arch/arm/mach-mcs814x/include/mach/hardware.h new file +4
-0+#include "mcs814x.h" + +#endif +arch/arm/mach- renamed from arch/arm/mach-mcs814x/include/mach/irqs.h +0
-0
mcs814x/include/mach/irqs.h
Quoted 23 lines
Quoted 10 lines
new file mode 100644
index 0000000..78021d1arch/arm/mach-mcs814x/include/mach/irqs.h new file +5
-0@@ -0,0 +1,22 @@ +/* +* Copyright (C) 2003 Artec Design Ltd. +* +* 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 arch/arm/mach-mcs814x/include/mach/irqs.h line 15
Quoted 10 lines
arch/arm/mach-mcs814x/include/mach/irqs.h new file +10
-0+* published by the Free Software Foundation. +* +*/ + +#ifndef __ASM_ARCH_IRQS_H +#define __ASM_ARCH_IRQS_H + +#define FIQ_START 0 + +#define NR_IRQS 32I think this shouldn't be needed if you use
SPARSE_IRQsupport.
Quoted 6 lines
arch/arm/mach-mcs814x/include/mach/irqs.h line 20
Quoted 4 lines
arch/arm/mach-mcs814x/include/mach/irqs.h new file +4
-0+#define IRQ_PCI_INTA 22 +#define IRQ_PCI_INTB 23 +#define IRQ_PCI_INTC 24 +#define IRQ_PCI_INTD 26And these probably belong to the DT somehow?
This would need a complete PCI irq mapping representation, so far we have the DT properties, but not the corresponding code to parse them. I would not qualify this as a major blocker.
Quoted 4 lines
Quoted 4 lines
arch/arm/mach-mcs814x/timer.c new file +0
-0
[snip]
Quoted 28 lines
Quoted 28 lines
arch/arm/mach-mcs814x/timer.c new file +28
-0+ +static void __init mcs814x_timer_init (void ) +{ +struct clk *clk; + + clk =clk_get_sys ("timer0" ,NULL ); +if (IS_ERR_OR_NULL (clk)) +panic ("unable to get timer0 clock" ); + + clock_rate =clk_get_rate (clk); +clk_put (clk); + +mcs814x_of_timer_init (); + +pr_info ("Timer frequency: %d (kHz)\n" , clock_rate /1000 ); + + timer_reload_value =0xffffffff - (clock_rate /HZ ); + +/* disable timer */ +__raw_writel (0 , mcs814x_timer_base +TIMER_CTL ); +__raw_writel (timer_reload_value, mcs814x_timer_base +TIMER_VAL ); + last_reload = timer_reload_value; + +setup_irq (mcs814x_timer_irq.irq, &mcs814x_timer_irq); +/* enable timer, stop timer in debug mode */ +__raw_writel (0x03 , mcs814x_timer_base +TIMER_CTL ); +} +
Quoted 8 lines
arch/arm/mach-mcs814x/timer.c line 133
Quoted 4 lines
arch/arm/mach-mcs814x/timer.c new file +4
-0+struct sys_timer mcs814x_timer = { + .init = mcs814x_timer_init, + .offset = mcs814x_gettimeoffset, +};I am surprised that this doesn't use the clocksource and clockevents infrastructure. It probably should, and be implemented in
drivers/clocksource/.
I will look into this, considering that we still have 2 timers left available (64-bits and 16-bits) this should be doable.
Thank you for your comments, I will wait a little more for other people to come up before coming up with a patch respin.
--
Florian
PATCH 1/8 ARM: support for Moschip MCS814x SoCs
Quoted 11 lines · Florian Fainelli
Quoted 7 lines
arch/arm/mach-mcs814x/include/mach/irqs.h line 20
Quoted 5 lines
arch/arm/mach-mcs814x/include/mach/irqs.h new file +4
-0+#define IRQ_PCI_INTA 22 +#define IRQ_PCI_INTB 23 +#define IRQ_PCI_INTC 24 +#define IRQ_PCI_INTD 26And these probably belong to the DT somehow?
This would need a complete PCI irq mapping representation, so far we have the DT properties, but not the corresponding code to parse them. I would not qualify this as a major blocker.
Your map_irq function looks broken for anything but the PCI cards you actually tested, so I think it's better to use the common code for parsing the DT here.
Arnd
PATCH 1/8 ARM: support for Moschip MCS814x SoCs
In reply to Florian FainelliQuoted 22 lines · Florian Fainelli
Hi Thomas,
Quoted 6 lines · On Monday 16 July 2012 14:29:41 Thomas Petazzoni wrote:
Hello Florian,
Le Sun, 15 Jul 2012 16:49:07 +0200,
Florian Fainelli <[email protected]> a ?crit :arch/arm/mach-
Quoted 1 line
arch/arm/mach- renamed from arch/arm/mach-mcs814x/Makefile.boot +0
-0mcs814x/Makefile.boot
Quoted 11 lines
arch/arm/mach-mcs814x/Makefile.boot line 3
Quoted 8 lines
new file mode 100644
index 0000000..414db8barch/arm/mach-mcs814x/Makefile.boot new file +3
-0@@ -0,0 +1,3 @@ + zreladdr-y := 0x00008000 + params_phys-y := 0x00000008 + initrd_phys-y := 0x00400000params_phys-y and initrd_phys-y are useless for DT-based platforms, if I'm correct.
Quoted 1 line
Indeed, only zreladdr is actually required.
If you use CONFIG_AUTO_ZRELADDR then even zreladdr-y isn't needed.
Nicolas
PATCH 1/8 ARM: support for Moschip MCS814x SoCs
In reply to Thomas PetazzoniHello Thomas,
Quoted 2 lines · On Monday 16 July 2012 14:29:41 Thomas Petazzoni wrote:
Hello Florian,
[snip]
Quoted 47 lines
Quoted 47 lines
arch/arm/mach-mcs814x/timer.c new file +47
-0+static void __init mcs814x_of_timer_init (void ) +{ +struct device_node *np; +const unsigned int *intspec; + + np =of_find_matching_node (NULL , mcs814x_timer_ids); +if (!np) +panic ("unable to find compatible timer node in dtb" ); + + mcs814x_timer_base =of_iomap (np,0 ); +if (!mcs814x_timer_base) +panic ("unable to remap timer cpu registers" ); + + intspec =of_get_property (np,"interrupts" ,NULL ); +if (!intspec) +panic ("no interrupts property for timer" ); + + mcs814x_timer_irq.irq =be32_to_cpup (intspec); +} + +static void __init mcs814x_timer_init (void ) +{ +struct clk *clk; + + clk =clk_get_sys ("timer0" ,NULL ); +if (IS_ERR_OR_NULL (clk)) +panic ("unable to get timer0 clock" ); + + clock_rate =clk_get_rate (clk); +clk_put (clk); + +mcs814x_of_timer_init (); + +pr_info ("Timer frequency: %d (kHz)\n" , clock_rate /1000 ); + + timer_reload_value =0xffffffff - (clock_rate /HZ ); + +/* disable timer */ +__raw_writel (0 , mcs814x_timer_base +TIMER_CTL ); +__raw_writel (timer_reload_value, mcs814x_timer_base +TIMER_VAL ); + last_reload = timer_reload_value; + +setup_irq (mcs814x_timer_irq.irq, &mcs814x_timer_irq); +/* enable timer, stop timer in debug mode */ +__raw_writel (0x03 , mcs814x_timer_base +TIMER_CTL ); +} +
Quoted 8 lines
arch/arm/mach-mcs814x/timer.c line 133
Quoted 4 lines
arch/arm/mach-mcs814x/timer.c new file +4
-0+struct sys_timer mcs814x_timer = { + .init = mcs814x_timer_init, + .offset = mcs814x_gettimeoffset, +};I am surprised that this doesn't use the clocksource and clockevents infrastructure. It probably should, and be implemented in
drivers/clocksource/.
This may sound like a stupid question, but the big constraint with this SoC is that the timers do not reload themselves, and so far, I did not find out how I can handle this properly with a clocksource. I suppose that it should not be a big problem for the clockevent device however.
Has anyone any example of such particular case?
Signature · 1 line
Florian
PATCH 1/8 ARM: support for Moschip MCS814x SoCs
Quoted 11 lines · Florian Fainelli
[Thomas P]
Quoted 3 lines
I am surprised that this doesn't use the clocksource and clockevents infrastructure. It probably should, and be implemented in
drivers/clocksource/.This may sound like a stupid question, but the big constraint with this SoC is that the timers do not reload themselves, and so far, I did not find out how I can handle this properly with a clocksource. I suppose that it should not be a big problem for the clockevent device however.
Has anyone any example of such particular case?
Gah what horror.
So you don't have *anything* in your platform which is really continous and sufficiently fast?
Then try to get an IRQ to rearm and retrigger the timer to fire itself whenever it reloads and pray this doesn't add a skew too much. Bonus if you can use the NMI for this :-/
Yours,
Linus Walleij
PATCH 1/8 ARM: support for Moschip MCS814x SoCs
In reply to Florian FainelliQuoted 7 lines · Florian Fainelli
arch/arm/mach-mcs814x/Kconfig new file +1
-0@@ -0,0 +1,11 @@ +if ARCH_MCS814X
arch/arm/mach-mcs814x/Kconfig line 11
Quoted 10 lines
arch/arm/mach-mcs814x/Kconfig new file +10
-0+ +config MCS8140 + select CPU_ARM926T + bool + +menu "Moschip MCS8140 boards" + +endmenu + +endif
What values does the Kconfig file actually provide? I see that you are adding the boards here later, but I think it would be nice to just make the new platform a single Kconfig option with no individual board selection.
arch/arm/mach-mcs814x/Kconfig
Quoted 9 lines
arch/arm/mach-mcs814x/Kconfig new file +9
-0+struct clk { + struct clk *parent; /* parent clk */ + unsigned long rate; /* clock rate in Hz */ + unsigned long divider; /* clock divider */ + u32 usecount; /* reference count */ + struct clk_ops *ops; /* clock operation */ + u32 enable_reg; /* clock enable register */ + u32 enable_mask; /* clock enable mask */ +};
Platforms are now converting to the common clock framework in drivers/clk. Mike Turquette as the subsystem maintainer can probably judge better whether we should still be allowing new platforms with their own implementation of clk, but my feeling is that you should use the subsystem instead and add a driver in a subdirectory of drivers/clk instead of in the platform.
Quoted 1 line
+void
__iomem*mcs814x_sysdbg_base;
Does this have to be globally visible? I would recommend making it static.
Quoted 37 lines
arch/arm/mach-mcs814x/Kconfig new file +37
-0+ +struct cpu_mode { + const char *name; + int gpio_start; + int gpio_end; +}; + +static const struct cpu_mode cpu_modes[] = { + { + .name = "I2S", + .gpio_start = 4, + .gpio_end = 8, + }, + { + .name = "UART", + .gpio_start = 4, + .gpio_end = 9, + }, + { + .name = "External MII", + .gpio_start = 0, + .gpio_end = 16, + }, + { + .name = "Normal", + .gpio_start = -1, + .gpio_end = -1, + }, +}; + +void __init mcs814x_init_machine(void) +{ + u32 bs2, cpu_mode; + int gpio; + + bs2 = __raw_readl(mcs814x_sysdbg_base + SYSDBG_BS2); + cpu_mode = (bs2 >> CPU_MODE_SHIFT) & CPU_MODE_MASK;
arch/arm/mach-mcs814x/Kconfig
Quoted 10 lines
arch/arm/mach-mcs814x/Kconfig new file +10
-0+ + pr_info("CPU mode: %s\n", cpu_modes[cpu_mode].name); + + /* request the gpios since the pins are muxed for functionnality */ + for (gpio = cpu_modes[cpu_mode].gpio_start; + gpio == cpu_modes[cpu_mode].gpio_end; gpio++) { + if (gpio != -1) + gpio_request(gpio, cpu_modes[cpu_mode].name); + } +}
This looks like a very simple instance of a pinmux driver. I wonder if it's worth doing an actual pinctrl driver that knows about these modes and about the gpio handling of the platform. Maybe Linus Walleij can comment on that.
How is the cpu mode managed? Is it hardwired through something like strapping pins, or could you have a system that sets it dynamically based on what hardware is being plugged in?
Quoted 4 lines
arch/arm/mach-mcs814x/Kconfig new file +4
-0+void __init mcs814x_map_io(void) +{ + iotable_init(mcs814x_io_desc, ARRAY_SIZE(mcs814x_io_desc)); +
arch/arm/mach-mcs814x/Kconfig
Quoted 10 lines
arch/arm/mach-mcs814x/Kconfig new file +10
-0+ mcs814x_sysdbg_base = ioremap(MCS814X_IO_START + MCS814X_SYSDBG, + MCS814X_SYSDBG_SIZE); + if (!mcs814x_sysdbg_base) + panic("unable to remap sysdbg base"); +} + +void mcs814x_restart(char mode, const char *cmd) +{ + __raw_writel(~(1 << 31), mcs814x_sysdbg_base); +}
You should generally avoid using __raw_readl etc. and instead use readl/write or readl_relaxed/writel_relaxed.
Quoted 11 lines
arch/arm/mach-mcs814x/common.h new file +5
-0@@ -0,0 +1,15 @@ +#ifndef __ARCH_MCS814X_COMMON_H +#define __ARCH_MCS814X_COMMON_H + +#include <asm/mach/time.h> +
arch/arm/mach-mcs814x/common.h line 15
Quoted 10 lines
arch/arm/mach-mcs814x/common.h new file +10
-0+void mcs814x_map_io (void ); +void mcs814x_clk_init (void ); +void mcs814x_of_irq_init (void ); +void mcs814x_init_machine (void ); +void mcs814x_handle_irq (struct pt_regs *regs); +void mcs814x_restart (char mode,const char *cmd); +extern struct sys_timer mcs814x_timer; +extern void __iomem *mcs814x_sysdbg_base; + +#endif /* __ARCH_MCS814X_COMMON_H */
I think a lot of these don't actually need to be global if you combine some of the files.
Quoted 12 lines
arch/arm/mach-mcs814x/include/mach/cpu.h new file +6
-0@@ -0,0 +1,16 @@ +#ifndef __ASM_ARCH_CPU_H__ +#define __ASM_ARCH_CPU_H__ + +#include <asm/cputype.h> + +#define MCS8140_ID 0x41069260/* ARM926EJ-S */
arch/arm/mach-mcs814x/include/mach/cpu.h line 16
Quoted 10 lines
arch/arm/mach-mcs814x/include/mach/cpu.h new file +10
-0+#define MCS814X_MASK 0xff0ffff0 + +#ifdef CONFIG_MCS8140 +/* Moschip MCS8140 is based on an ARM926EJ-S core */ +#define soc_is_mcs8140 () ((read_cpuid_id() & MCS814X_MASK) == MCS8140_ID) +#else +#define soc_is_mcs8140 () (0) +#endif /* !CONFIG_MCS8140 */ + +#endif /* __ASM_ARCH_CPU_H__ */
Can you explain what this is used for? Are there other SoCs in the same platform that will get added later?
Quoted 11 lines
arch/arm/mach-mcs814x/include/mach/hardware.h new file +5
-0@@ -0,0 +1,16 @@ +/* +* Copyright (C) 2003 Artec Design Ltd. +* +* 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
arch/arm/mach-mcs814x/include/mach/hardware.h line 15
Quoted 10 lines
arch/arm/mach-mcs814x/include/mach/hardware.h new file +10
-0+* published by the Free Software Foundation. +* +*/ + +#ifndef __ASM_ARCH_HARDWARE_H +#define __ASM_ARCH_HARDWARE_H + +#include "mcs814x.h" + +#endif
I'd just make this an empty file, like gpio.h. That will let us kill off these files more easily in the future.
Quoted 9 lines
arch/arm/mach-mcs814x/include/mach/irqs.h new file +3
-0@@ -0,0 +1,22 @@ +/* +* Copyright (C) 2003 Artec Design Ltd. +*
arch/arm/mach-mcs814x/include/mach/irqs.h line 13
Quoted 10 lines
arch/arm/mach-mcs814x/include/mach/irqs.h new file +10
-0+* 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_IRQS_H +#define __ASM_ARCH_IRQS_H + +#define FIQ_START 0
Why do you need the FIQ_START macro here?
arch/arm/mach-mcs814x/include/mach/irqs.h line 20
Quoted 6 lines
arch/arm/mach-mcs814x/include/mach/irqs.h new file +6
-0+#define NR_IRQS 32 + +#define IRQ_PCI_INTA 22 +#define IRQ_PCI_INTB 23 +#define IRQ_PCI_INTC 24 +#define IRQ_PCI_INTD 26
The PCI interrupts should come from the device tree.
You should also select CONFIG_SPARSE_IRQ unconditionally and use IRQ domains so that you no longer need to set NR_IRQS.
Quoted 11 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +5
-0@@ -0,0 +1,53 @@ +/* +* Copyright (C) 2003 Artec Design Ltd. +* +* 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
arch/arm/mach-mcs814x/include/mach/mcs814x.h line 15
Quoted 10 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +10
-0+* published by the Free Software Foundation. +* +*/ + +#ifndef __ASM_ARCH_MCS814X_H +#define __ASM_ARCH_MCS814X_H + +#define MCS814X_IO_BASE 0xF0000000 +#define MCS814X_IO_START 0x40000000 +#define MCS814X_IO_SIZE 0x00100000
What are these required for in the global space? Can you move them into a single .c file?
arch/arm/mach-mcs814x/include/mach/mcs814x.h line 21
Quoted 5 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +5
-0+/* IRQ controller register offset */ +#define MCS814X_IRQ_ICR 0x00 +#define MCS814X_IRQ_ISR 0x04 +#define MCS814X_IRQ_MASK 0x20 +#define MCS814X_IRQ_STS0 0x40
I'm pretty sure these can be in irq.c
Quoted 18 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +18
-0+#define MCS814X_PHYS_BASE 0x40000000 +#define MCS814X_VIRT_BASE MCS814X_IO_BASE + +#define MCS814X_UART 0x000DC000 +#define MCS814X_DBGLED 0x000EC000 +#define MCS814X_SYSDBG 0x000F8000 +#define MCS814X_SYSDBG_SIZE 0x50 + +/* System configuration and bootstrap registers */ +#define SYSDBG_BS1 0x00 +#define CPU_FREQ_SHIFT 27 +#define CPU_FREQ_MASK 0x0F +#define SDRAM_FREQ_BIT (1 << 22) + +#define SYSDBG_BS2 0x04 +#define LED_CFG_MASK 0x03 +#define CPU_MODE_SHIFT 23 +#define CPU_MODE_MASK 0x03
arch/arm/mach-mcs814x/include/mach/mcs814x.h line 50
Quoted 10 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +10
-0+ +#define SYSDBG_SYSCTL_MAC 0x1d +#define BUF_SHIFT_BIT (1 << 0) + +#define SYSDBG_SYSCTL 0x08 +#define SYSCTL_EMAC (1 << 0) +#define SYSCTL_EPHY (1 << 0)/* active low */ +#define SYSCTL_CIPHER (1 << 16) + +#define SYSDBG_PLL_CTL 0x3C
The sysdbg stuff can probably go into a file that deals with the sysdbg registers and exports a high-level interface.
arch/arm/mach-mcs814x/include/mach/mcs814x.h line 50
Quoted 2 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +2
-0+ +void __iomem *mcs814x_intc_base;
static?
Quoted 14 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +13
-0+#define MCS8140_PCI_HOST_BASE 0x80000000 +#define MCS8140_PCI_IOMISC_BASE 0x00000000 +#define MCS8140_PCI_PRE_BASE 0x10000000 +#define MCS8140_PCI_NONPRE_BASE 0x30000000 + +#define MCS8140_PCI_CFG_BASE (MCS8140_PCI_HOST_BASE + 0x04000000) +#define MCS8140_PCI_IO_BASE (MCS8140_PCI_HOST_BASE) + +#define MCS8140_PCI_IO_VIRT_BASE (MCS814X_IO_BASE - \ + MCS8140_PCI_CONFIG_SIZE - \ + MCS8140_PCI_IOMISC_SIZE) +#define MCS8140_PCI_CFG_VIRT_BASE (MCS814X_IO_BASE - \ + MCS8140_PCI_CONFIG_SIZE)
arch/arm/mach-mcs814x/include/mach/mcs814x.h
Quoted 10 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +9
-0+static unsigned long __pci_addr (struct pci_bus *bus, +unsigned int devfn,int offset) +{ +unsigned int busnr = bus->number; +unsigned int slot; + +/* we only support bus 0 */ +if (busnr !=0 ) +return 0 ;
Why? A lot of devices have bridges on them and they should just work if you take out this check.
arch/arm/mach-mcs814x/include/mach/mcs814x.h
Quoted 4 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +4
-0+/* +* Trap out illegal values +*/ +BUG_ON (devfn >255 || busnr >255 || devfn >255 );
You're checking devfn twice...
arch/arm/mach-mcs814x/include/mach/mcs814x.h
Quoted 8 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +8
-0+/* Scan 3 slots */ + slot =PCI_SLOT (devfn); +switch (slot) { +case 1 : +case 2 : +case 3 : +if (PCI_FUNC (devfn) >=4 ) +return 0 ;
This also looks bogus. Why limit it to three devices?
Quoted 13 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +13
-0+static int mcs8140_pci_read_config (struct pci_bus *bus, +unsigned int devfn,int where, +int size,u32 *val) +{ +unsigned long v =0xFFFFFFFF ; +unsigned long addr =__pci_addr (bus, devfn, where); + +if (addr !=0 ) { +switch (size) { +case 1 : + v =__raw_readb (addr); +break ; +case 2 :
arch/arm/mach-mcs814x/include/mach/mcs814x.h
Quoted 10 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +10
-0+ addr &= ~1 ; + v =__raw_readw (addr); +break ; +default : + addr &= ~3 ; + v =__raw_readl (addr); +break ; + } + }else + v =0xffffffff ;
This is just mmconfig, right? Don't we have a generic implementation for that?
arch/arm/mach-mcs814x/include/mach/mcs814x.h
Quoted 7 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +7
-0+ +static struct resource io_mem = { + .name ="PCI I/O space" , + .start =MCS8140_PCI_HOST_BASE +MCS8140_PCI_IOMISC_BASE , + .end =MCS8140_PCI_HOST_BASE +MCS8140_PCI_IOMISC_BASE +SZ_64M , + .flags =IORESOURCE_IO , +};
This is wrong: MCS8140_PCI_HOST_BASE is an address in IORESOURCE_MEM space. You probably also mean SZ_64K instead of SZ_64M.
arch/arm/mach-mcs814x/include/mach/mcs814x.h
Quoted 9 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +9
-0+int __init pci_mcs8140_setup (int nr,struct pci_sys_data *sys) +{ +int ret =0 ; +u32 val; + +if (nr >0 ) +return 0 ; + + sys->mem_offset =MCS8140_PCI_IO_VIRT_BASE -MCS8140_PCI_IO_BASE ;
Your address spaces are very confusing (or confused). So you have defined
#define MCS8140_PCI_IO_VIRT_BASE (MCS814X_IO_BASE - \
MCS8140_PCI_CONFIG_SIZE - \
MCS8140_PCI_IOMISC_SIZE)
#define MCS8140_PCI_CFG_VIRT_BASE (MCS814X_IO_BASE - \
MCS8140_PCI_CONFIG_SIZE)which means you mem_offset is (MCS814X_IO_BASE - MCS8140_PCI_CONFIG_SIZE - MCS8140_PCI_IOMISC_SIZE) - (MCS814X_IO_BASE - MCS8140_PCI_CONFIG_SIZE) which is (-MCS8140_PCI_IOMISC_SIZE), which in turn evaluates to -SZ_64M or 0xfc000000. If that is the correct value, I'm sure it's just coincidence ;-)
Quoted 7 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +7
-0+static int __init mcs8140_map_irq (const struct pci_dev *dev,u8 slot,u8 pin) +{ +int line =IRQ_PCI_INTA ; + +if (pin !=0 ) { +/* IRQ_PCIA - 22 */ +if (pin ==PCI_INTD )
arch/arm/mach-mcs814x/include/mach/mcs814x.h
Quoted 10 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +10
-0+ line =IRQ_PCI_INTA + pin;/* IRQ_PCIA - 22 */ + else + line =IRQ_PCI_INTA + pin -1 ;/* IRQ_PCIA - 22 */ + } + +pr_info ("PCI: Map interrupt slot 0x%02x pin 0x%02x line 0x%02x\n" , + slot, pin, line); + +return line; +}
This looks like a very unusual mapping. Maybe it's just wrong and that explains why you don't support child buses or additional slots?
In any case, you should use an "interrupt-map" in the device tree that describes how the IRQs are mapped to the slots. I think we have generic code to deal with that already.
Quoted 4 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +4
-0+static struct map_desc mcs8140_pci_io_desc[]__initdata = { + { + .virtual =MCS8140_PCI_CFG_VIRT_BASE , + .pfn =__phys_to_pfn (MCS8140_PCI_CFG_BASE ),
arch/arm/mach-mcs814x/include/mach/mcs814x.h
Quoted 10 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +10
-0+ .length = MCS8140_PCI_CONFIG_SIZE, + .type = MT_DEVICE + }, + { + .virtual = MCS8140_PCI_IO_VIRT_BASE, + .pfn = __phys_to_pfn(MCS8140_PCI_IO_BASE), + .length = MCS8140_PCI_IOMISC_SIZE, + .type = MT_DEVICE + }, +};
Please have a look at the latest patches from Rob Herring about mapping the I/O space. I don't think you need to map the config space early because you don't rely on a fixed location for that. Just use of_iomap() to find that and store the pointer to the config space somewhere.
arch/arm/mach-mcs814x/include/mach/mcs814x.h
Quoted 1 line
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +1
-0+ pcibios_min_io =MCS8140_PCI_HOST_BASE ;
Leave this one at the default of 0x1000. MCS8140_PCI_HOST_BASE is the address from the CPU's point of view, not from the bus. You just need to stay out of the range of possible legacy ISA devices.
It's probably a good idea to keep the PCI support as a separate patch for reviewing purposes.
Arnd
PATCH 1/8 ARM: support for Moschip MCS814x SoCs
Quoted 25 lines · Arnd Bergmann
Quoted 7 lines · Florian Fainelli
arch/arm/mach-mcs814x/Kconfig new file +1
-0@@ -0,0 +1,11 @@ +if ARCH_MCS814Xarch/arm/mach-mcs814x/Kconfig line 11
Quoted 10 lines
arch/arm/mach-mcs814x/Kconfig new file +10
-0+ +config MCS8140 + select CPU_ARM926T + bool + +menu "Moschip MCS8140 boards" + +endmenu + +endifWhat values does the
Kconfigfile actually provide? I see that you are adding the boards here later, but I think it would be nice to just make the new platform a singleKconfigoption with no individual board selection.
Quoted 16 lines
arch/arm/mach-mcs814x/Kconfig
Quoted 9 lines
arch/arm/mach-mcs814x/Kconfig new file +9
-0+struct clk { + struct clk *parent; /* parent clk */ + unsigned long rate; /* clock rate in Hz */ + unsigned long divider; /* clock divider */ + u32 usecount; /* reference count */ + struct clk_ops *ops; /* clock operation */ + u32 enable_reg; /* clock enable register */ + u32 enable_mask; /* clock enable mask */ +};Platforms are now converting to the common clock framework in
drivers/clk. Mike Turquette as the subsystem maintainer can probably judge better whether we should still be allowing new platforms with their own implementation of clk, but my feeling is that you should use the subsystem instead and add a driver in a subdirectory ofdrivers/clkinstead of in the platform.
Hi Florian & Arnd,
Adopting the new clock framework is highly preferable, especially if MCS814x support is being delayed until 3.7. There is also a push to put clock drivers into drivers/clk and I would like to continue that trend, but I'm less strict on that measure if it proves very difficult for your platform immediately (e.g. duplicating headers across platform and generic code, etc). Migrating code from arch/arm to drivers/clk can always be done in a future series.
This platform also seems to be making use of DT so it would be very nice if we use MCS814x to push the state of clk DT bindings and adoption forward a bit. There are not a lot of folks using the patches from Rob/Grant today. Hopefully delaying these patches by another merge cycle means that these requests are not asking too much :-)
Regards,
Mike
PATCH 1/8 ARM: support for Moschip MCS814x SoCs
Hi Mike,
Quoted 1 line · Mike
On Mon, Jul 16, 2012 at 8:54 AM, Arnd Bergmann <[email protected]> wrote:
[snip]
Quoted 14 lines
Quoted 14 lines
board selection.
arch/arm/mach-mcs814x/clock.c line 39
Quoted 9 lines
arch/arm/mach-mcs814x/clock.c new file +9
-0+struct clk { +struct clk *parent;/* parent clk */ +unsigned long rate;/* clock rate in Hz */ +unsigned long divider;/* clock divider */ +u32 usecount;/* reference count */ +struct clk_ops *ops;/* clock operation */ +u32 enable_reg;/* clock enable register */ +u32 enable_mask;/* clock enable mask */ +};Platforms are now converting to the common clock framework in
drivers/clk. Mike Turquette as the subsystem maintainer can probably judge better
whether
Quoted 7 lines
Quoted 4 lines
we should still be allowing new platforms with their own implementation of clk, but my feeling is that you should use the subsystem instead and add a driver in a subdirectory of
drivers/clkinstead of in the platform.Hi Florian & Arnd,
Quoted 7 lines
Adopting the new clock framework is highly preferable, especially if MCS814x support is being delayed until 3.7. There is also a push to put clock drivers into
drivers/clkand I would like to continue that trend, but I'm less strict on that measure if it proves very difficult for your platform immediately (e.g. duplicating headers across platform and generic code, etc). Migrating code fromarch/armtodrivers/clkcan always be done in a future series.
Since we are now targetting 3.7, I would rather come up with proper DT clock bindings, which should make the mcs814x clock driver much nicer.
Quoted 7 lines
This platform also seems to be making use of DT so it would be very nice if we use MCS814x to push the state of clk DT bindings and adoption forward a bit. There are not a lot of folks using the patches from Rob/Grant today. Hopefully delaying these patches by another merge cycle means that these requests are not asking too much :-)
If we could get them merged during 3.6 that would allow me, and other ARM-soc maintainers to get their stuff fully migrated to DT. Are there any blockers to these patches?
--
Florian
PATCH 1/8 ARM: support for Moschip MCS814x SoCs
In reply to Turquette, MikeHi Mike,
Quoted 1 line · Mike
On Mon, Jul 16, 2012 at 8:54 AM, Arnd Bergmann <[email protected]> wrote:
[snip]
Quoted 14 lines
Quoted 14 lines
board selection.
arch/arm/mach-mcs814x/clock.c line 39
Quoted 9 lines
arch/arm/mach-mcs814x/clock.c new file +9
-0+struct clk { +struct clk *parent;/* parent clk */ +unsigned long rate;/* clock rate in Hz */ +unsigned long divider;/* clock divider */ +u32 usecount;/* reference count */ +struct clk_ops *ops;/* clock operation */ +u32 enable_reg;/* clock enable register */ +u32 enable_mask;/* clock enable mask */ +};Platforms are now converting to the common clock framework in
drivers/clk. Mike Turquette as the subsystem maintainer can probably judge better
whether
Quoted 7 lines
Quoted 4 lines
we should still be allowing new platforms with their own implementation of clk, but my feeling is that you should use the subsystem instead and add a driver in a subdirectory of
drivers/clkinstead of in the platform.Hi Florian & Arnd,
Quoted 7 lines
Adopting the new clock framework is highly preferable, especially if MCS814x support is being delayed until 3.7. There is also a push to put clock drivers into
drivers/clkand I would like to continue that trend, but I'm less strict on that measure if it proves very difficult for your platform immediately (e.g. duplicating headers across platform and generic code, etc). Migrating code fromarch/armtodrivers/clkcan always be done in a future series.
Since we are now targetting 3.7, I would rather come up with proper DT clock bindings, which should make the mcs814x clock driver much nicer.
Quoted 7 lines
This platform also seems to be making use of DT so it would be very nice if we use MCS814x to push the state of clk DT bindings and adoption forward a bit. There are not a lot of folks using the patches from Rob/Grant today. Hopefully delaying these patches by another merge cycle means that these requests are not asking too much :-)
If we could get them merged during 3.6 that would allow me, and other ARM-soc maintainers to get their stuff fully migrated to DT. Are there any blockers to these patches?
--
Florian
PATCH 1/8 ARM: support for Moschip MCS814x SoCs
In reply to Arnd BergmannQuoted 37 lines · Arnd Bergmann
Quoted 37 lines
arch/arm/mach-mcs814x/common.c new file +37
-0+static const struct cpu_mode cpu_modes[] = { + { + .name ="I2S" , + .gpio_start =4 , + .gpio_end =8 , + }, + { + .name ="UART" , + .gpio_start =4 , + .gpio_end =9 , + }, + { + .name ="External MII" , + .gpio_start =0 , + .gpio_end =16 , + }, + { + .name ="Normal" , + .gpio_start =-1 , + .gpio_end =-1 , + }, +}; + +void __init mcs814x_init_machine (void ) +{ +u32 bs2, cpu_mode; +int gpio; + + bs2 =__raw_readl (mcs814x_sysdbg_base +SYSDBG_BS2 ); + cpu_mode = (bs2 >>CPU_MODE_SHIFT ) &CPU_MODE_MASK ; + +pr_info ("CPU mode: %s\n" , cpu_modes[cpu_mode].name); + +/* request the gpios since the pins are muxed for functionnality */ +for (gpio = cpu_modes[cpu_mode].gpio_start; + gpio == cpu_modes[cpu_mode].gpio_end; gpio++) { +if (gpio !=-1 )
Quoted 8 lines
arch/arm/mach-mcs814x/common.c line 82
Quoted 3 lines
arch/arm/mach-mcs814x/common.c new file +3
-0+gpio_request (gpio, cpu_modes[cpu_mode].name); + } +}This looks like a very simple instance of a pinmux driver. I wonder if it's worth doing an actual pinctrl driver that knows about these modes and about the gpio handling of the platform. Maybe Linus Walleij can comment on that.
It is worth, because usually it is not simple at all but these are, as I highly suspect, the first few entries to get the platform up and running. Then it's going to need to add another one, and then another one, and then break it into a separate file, and then it's a custom pin controller implementation all over again
Nothing is forbidding a simple pin controller implementation in drivers/pinctrl, just a few tens of lines is perfectly OK with me.
Documentation/pinctrl.txt is the friend at all times. arch/arm/mach-u300/core.c shows how a simple set-up at boot time can be achieved using so-called pinctrl hogs.
Yours,
Linus Walleij
PATCH 1/8 ARM: support for Moschip MCS814x SoCs
Quoted 54 lines · On Tuesday 17 July 2012 00:12:01 Linus Walleij wrote:
Quoted 37 lines · Arnd Bergmann
Quoted 37 lines
arch/arm/mach-mcs814x/common.c new file +37
-0+static const struct cpu_mode cpu_modes[] = { + { + .name ="I2S" , + .gpio_start =4 , + .gpio_end =8 , + }, + { + .name ="UART" , + .gpio_start =4 , + .gpio_end =9 , + }, + { + .name ="External MII" , + .gpio_start =0 , + .gpio_end =16 , + }, + { + .name ="Normal" , + .gpio_start =-1 , + .gpio_end =-1 , + }, +}; + +void __init mcs814x_init_machine (void ) +{ +u32 bs2, cpu_mode; +int gpio; + + bs2 =__raw_readl (mcs814x_sysdbg_base +SYSDBG_BS2 ); + cpu_mode = (bs2 >>CPU_MODE_SHIFT ) &CPU_MODE_MASK ; + +pr_info ("CPU mode: %s\n" , cpu_modes[cpu_mode].name); + +/* request the gpios since the pins are muxed for functionnality */ +for (gpio = cpu_modes[cpu_mode].gpio_start; + gpio == cpu_modes[cpu_mode].gpio_end; gpio++) { +if (gpio !=-1 )Quoted 8 lines
arch/arm/mach-mcs814x/common.c line 82
Quoted 3 lines
arch/arm/mach-mcs814x/common.c new file +3
-0+gpio_request (gpio, cpu_modes[cpu_mode].name); + } +}This looks like a very simple instance of a pinmux driver. I wonder if it's worth doing an actual pinctrl driver that knows about these modes and about the gpio handling of the platform. Maybe Linus Walleij can comment on that.
It is worth, because usually it is not simple at all but these are, as I highly suspect, the first few entries to get the platform up and running. Then it's going to need to add another one, and then another one, and then break it into a separate file, and then it's a custom pin controller implementation all over again
Quoted 3 lines
Nothing is forbidding a simple pin controller implementation in
drivers/pinctrl, just a few tens of lines is perfectly OK with me.
In this particular case, I do not think it is even worth having a pinctrl driver since the settings are hardwired using bootstrap registers, so we cannot runtime change them afterwards.
Quoted 8 lines
Documentation/pinctrl.txtis the friend at all times.arch/arm/mach-u300/core.cshows how a simple set-up at boot time can be achieved using so-called pinctrl hogs.Yours,
Linus Walleij
PATCH 1/8 ARM: support for Moschip MCS814x SoCs
In reply to Arnd BergmannHi Arnd,
Quoted 16 lines · On Monday 16 July 2012 15:54:04 Arnd Bergmann wrote:
Quoted 14 lines · Florian Fainelli
arch/arm/mach-mcs814x/Kconfig new file +8
-0@@ -0,0 +1,11 @@ +if ARCH_MCS814X + +config MCS8140 + select CPU_ARM926T + bool + +menu "Moschip MCS8140 boards" +
Quoted 8 lines
arch/arm/mach-mcs814x/Kconfig line 11
Quoted 3 lines
arch/arm/mach-mcs814x/Kconfig new file +3
-0+endmenu + +endifWhat values does the
Kconfigfile actually provide? I see that you are adding the boards here later, but I think it would be nice to just make the new platform a singleKconfigoption with no individual board selection.
I plan on adding support for MCS8142 later on, thus I thought it would be nice to be able to selectively compile board support for MCS8140 or some later chip.
Quoted 18 lines
arch/arm/mach-mcs814x/Kconfig
Quoted 10 lines
arch/arm/mach-mcs814x/Kconfig new file +9
-0+struct clk { + struct clk *parent; /* parent clk */ + unsigned long rate; /* clock rate in Hz */ + unsigned long divider; /* clock divider */ + u32 usecount; /* reference count */ + struct clk_ops *ops; /* clock operation */ + u32 enable_reg; /* clock enable register */ + u32 enable_mask; /* clock enable mask */ +};Platforms are now converting to the common clock framework in
drivers/clk. Mike Turquette as the subsystem maintainer can probably judge better whether we should still be allowing new platforms with their own implementation of clk, but my feeling is that you should use the subsystem instead and add a driver in a subdirectory ofdrivers/clkinstead of in the platform.
Quoted 3 lines
Quoted 1 line
+void
__iomem*mcs814x_sysdbg_base;Does this have to be globally visible? I would recommend making it static.
Yes, since it is used both by clock.c and common.c
Quoted 54 lines
Quoted 38 lines
arch/arm/mach-mcs814x/Kconfig new file +37
-0+ +struct cpu_mode { + const char *name; + int gpio_start; + int gpio_end; +}; + +static const struct cpu_mode cpu_modes[] = { + { + .name = "I2S", + .gpio_start = 4, + .gpio_end = 8, + }, + { + .name = "UART", + .gpio_start = 4, + .gpio_end = 9, + }, + { + .name = "External MII", + .gpio_start = 0, + .gpio_end = 16, + }, + { + .name = "Normal", + .gpio_start = -1, + .gpio_end = -1, + }, +}; + +void __init mcs814x_init_machine(void) +{ + u32 bs2, cpu_mode; + int gpio; + + bs2 = __raw_readl(mcs814x_sysdbg_base + SYSDBG_BS2); + cpu_mode = (bs2 >> CPU_MODE_SHIFT) & CPU_MODE_MASK;arch/arm/mach-mcs814x/Kconfig
Quoted 10 lines
arch/arm/mach-mcs814x/Kconfig new file +10
-0+ + pr_info("CPU mode: %s\n", cpu_modes[cpu_mode].name); + + /* request the gpios since the pins are muxed for functionnality */ + for (gpio = cpu_modes[cpu_mode].gpio_start; + gpio == cpu_modes[cpu_mode].gpio_end; gpio++) { + if (gpio != -1) + gpio_request(gpio, cpu_modes[cpu_mode].name); + } +}This looks like a very simple instance of a pinmux driver. I wonder if it's worth doing an actual pinctrl driver that knows about these modes and about the gpio handling of the platform. Maybe Linus Walleij can comment on that.
Quoted 3 lines
How is the cpu mode managed? Is it hardwired through something like strapping pins, or could you have a system that sets it dynamically based on what hardware is being plugged in?
Like I replied to Thomas, these settings are actually hardwired through bootstrap registers, so I should not even bother to request these GPIOs.
Quoted 10 lines
Quoted 10 lines
arch/arm/mach-mcs814x/Kconfig new file +9
-0+void __init mcs814x_map_io(void) +{ + iotable_init(mcs814x_io_desc, ARRAY_SIZE(mcs814x_io_desc)); + + mcs814x_sysdbg_base = ioremap(MCS814X_IO_START + MCS814X_SYSDBG, + MCS814X_SYSDBG_SIZE); + if (!mcs814x_sysdbg_base) + panic("unable to remap sysdbg base"); +}
Quoted 8 lines
arch/arm/mach-mcs814x/Kconfig
Quoted 5 lines
arch/arm/mach-mcs814x/Kconfig new file +5
-0+ +void mcs814x_restart(char mode, const char *cmd) +{ + __raw_writel(~(1 << 31), mcs814x_sysdbg_base); +}You should generally avoid using
__raw_readletc. and instead use readl/write or readl_relaxed/writel_relaxed.
Allright, even on an ARM926-EJS-based system?
Quoted 2 lines
arch/arm/mach-
Quoted 2 lines
arch/arm/mach- renamed from arch/arm/mach-mcs814x/common.h +0
-0
mcs814x/common.h
Quoted 25 lines
Quoted 10 lines
new file mode 100644
index 0000000..e523abearch/arm/mach-mcs814x/common.h new file +5
-0@@ -0,0 +1,15 @@ +#ifndef __ARCH_MCS814X_COMMON_H +#define __ARCH_MCS814X_COMMON_H + +#include <asm/mach/time.h> +arch/arm/mach-mcs814x/common.h line 15
Quoted 10 lines
arch/arm/mach-mcs814x/common.h new file +10
-0+void mcs814x_map_io (void ); +void mcs814x_clk_init (void ); +void mcs814x_of_irq_init (void ); +void mcs814x_init_machine (void ); +void mcs814x_handle_irq (struct pt_regs *regs); +void mcs814x_restart (char mode,const char *cmd); +extern struct sys_timer mcs814x_timer; +extern void __iomem *mcs814x_sysdbg_base; + +#endif /* __ARCH_MCS814X_COMMON_H */ I think a lot of these don't actually need to be global if you combine some of the files.
Quoted 1 line
arch/arm/mach-
Quoted 1 line
arch/arm/mach- renamed from arch/arm/mach-mcs814x/include/mach/cpu.h +0
-0
mcs814x/include/mach/cpu.h
Quoted 16 lines
Quoted 16 lines
new file mode 100644
index 0000000..1ef3c4aarch/arm/mach-mcs814x/include/mach/cpu.h new file +11
-0@@ -0,0 +1,16 @@ +#ifndef __ASM_ARCH_CPU_H__ +#define __ASM_ARCH_CPU_H__ + +#include <asm/cputype.h> + +#define MCS8140_ID 0x41069260/* ARM926EJ-S */ +#define MCS814X_MASK 0xff0ffff0 + +#ifdef CONFIG_MCS8140 +/* Moschip MCS8140 is based on an ARM926EJ-S core */ +#define soc_is_mcs8140 () ((read_cpuid_id() & MCS814X_MASK) == MCS8140_ID)
Quoted 8 lines
arch/arm/mach-mcs814x/include/mach/cpu.h line 16
Quoted 5 lines
arch/arm/mach-mcs814x/include/mach/cpu.h new file +5
-0+#else +#define soc_is_mcs8140 () (0) +#endif /* !CONFIG_MCS8140 */ + +#endif /* __ASM_ARCH_CPU_H__ */ Can you explain what this is used for? Are there other SoCs in the same platform that will get added later?
Yes, that's the plan.
Quoted 2 lines
arch/arm/mach-
Quoted 2 lines
arch/arm/mach- renamed from arch/arm/mach-mcs814x/include/mach/hardware.h +0
-0
mcs814x/include/mach/hardware.h
Quoted 15 lines
Quoted 15 lines
new file mode 100644
index 0000000..529f648arch/arm/mach-mcs814x/include/mach/hardware.h new file +10
-0@@ -0,0 +1,16 @@ +/* +* Copyright (C) 2003 Artec Design Ltd. +* +* 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
Quoted 8 lines
arch/arm/mach-mcs814x/include/mach/hardware.h line 15
Quoted 5 lines
arch/arm/mach-mcs814x/include/mach/hardware.h new file +5
-0+#define __ASM_ARCH_HARDWARE_H + +#include "mcs814x.h" + +#endif I'd just make this an empty file, like
gpio.h. That will let us kill off these files more easily in the future.
Ok.
Quoted 2 lines
arch/arm/mach-
Quoted 2 lines
arch/arm/mach- renamed from arch/arm/mach-mcs814x/include/mach/irqs.h +0
-0
mcs814x/include/mach/irqs.h
Quoted 12 lines
Quoted 12 lines
new file mode 100644
index 0000000..78021d1arch/arm/mach-mcs814x/include/mach/irqs.h new file +7
-0@@ -0,0 +1,22 @@ +/* +* Copyright (C) 2003 Artec Design Ltd. +* +* 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. +*
Quoted 8 lines
arch/arm/mach-mcs814x/include/mach/irqs.h line 13
Quoted 6 lines
arch/arm/mach-mcs814x/include/mach/irqs.h new file +6
-0+*/ + +#ifndef __ASM_ARCH_IRQS_H +#define __ASM_ARCH_IRQS_H + +#define FIQ_START 0Why do you need the
FIQ_STARTmacro here?
I don't think I need this anymore.
Quoted 10 lines
arch/arm/mach-mcs814x/include/mach/irqs.h line 20
Quoted 7 lines
arch/arm/mach-mcs814x/include/mach/irqs.h new file +6
-0+#define NR_IRQS 32 + +#define IRQ_PCI_INTA 22 +#define IRQ_PCI_INTB 23 +#define IRQ_PCI_INTC 24 +#define IRQ_PCI_INTD 26The PCI interrupts should come from the device tree.
Quoted 2 lines
You should also select
CONFIG_SPARSE_IRQunconditionally and use IRQ domains so that you no longer need to setNR_IRQS.
Ok.
Quoted 2 lines
arch/arm/mach-
Quoted 2 lines
arch/arm/mach- renamed from arch/arm/mach-mcs814x/include/mach/mcs814x.h +0
-0
mcs814x/include/mach/mcs814x.h
Quoted 15 lines
Quoted 15 lines
new file mode 100644
index 0000000..a4a369earch/arm/mach-mcs814x/include/mach/mcs814x.h new file +10
-0@@ -0,0 +1,53 @@ +/* +* Copyright (C) 2003 Artec Design Ltd. +* +* 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_MCS814X_H
Quoted 8 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h line 15
Quoted 5 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +5
-0+#define __ASM_ARCH_MCS814X_H + +#define MCS814X_IO_BASE 0xF0000000 +#define MCS814X_IO_START 0x40000000 +#define MCS814X_IO_SIZE 0x00100000What are these required for in the global space? Can you move them into a single .c file?
I can certainly do this.
Quoted 8 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h line 21
Quoted 6 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +5
-0+/* IRQ controller register offset */ +#define MCS814X_IRQ_ICR 0x00 +#define MCS814X_IRQ_ISR 0x04 +#define MCS814X_IRQ_MASK 0x20 +#define MCS814X_IRQ_STS0 0x40I'm pretty sure these can be in
irq.c
Not unless I switch to MULTI_IRQ_HANDLER.
Quoted 33 lines
Quoted 19 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +18
-0+#define MCS814X_PHYS_BASE 0x40000000 +#define MCS814X_VIRT_BASE MCS814X_IO_BASE + +#define MCS814X_UART 0x000DC000 +#define MCS814X_DBGLED 0x000EC000 +#define MCS814X_SYSDBG 0x000F8000 +#define MCS814X_SYSDBG_SIZE 0x50 + +/* System configuration and bootstrap registers */ +#define SYSDBG_BS1 0x00 +#define CPU_FREQ_SHIFT 27 +#define CPU_FREQ_MASK 0x0F +#define SDRAM_FREQ_BIT (1 << 22) + +#define SYSDBG_BS2 0x04 +#define LED_CFG_MASK 0x03 +#define CPU_MODE_SHIFT 23 +#define CPU_MODE_MASK 0x03arch/arm/mach-mcs814x/include/mach/mcs814x.h line 50
Quoted 10 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +10
-0+ +#define SYSDBG_SYSCTL_MAC 0x1d +#define BUF_SHIFT_BIT (1 << 0) + +#define SYSDBG_SYSCTL 0x08 +#define SYSCTL_EMAC (1 << 0) +#define SYSCTL_EPHY (1 << 0)/* active low */ +#define SYSCTL_CIPHER (1 << 16) + +#define SYSDBG_PLL_CTL 0x3CThe sysdbg stuff can probably go into a file that deals with the sysdbg registers and exports a high-level interface.
Quoted 4 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h line 50
Quoted 2 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +2
-0+ +void __iomem *mcs814x_intc_base;static?
Since I am not yet using MULTI_IRQ_HANDLER, this is used by the entry-macro.S file too.
Quoted 7 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h
Quoted 7 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +6
-0+#define MCS8140_PCI_HOST_BASE 0x80000000 +#define MCS8140_PCI_IOMISC_BASE 0x00000000 +#define MCS8140_PCI_PRE_BASE 0x10000000 +#define MCS8140_PCI_NONPRE_BASE 0x30000000 + +#define MCS8140_PCI_CFG_BASE (MCS8140_PCI_HOST_BASE +
0x04000000)
Quoted 57 lines
Quoted 8 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +7
-0+#define MCS8140_PCI_IO_BASE (MCS8140_PCI_HOST_BASE) + +#define MCS8140_PCI_IO_VIRT_BASE (MCS814X_IO_BASE - \ + MCS8140_PCI_CONFIG_SIZE - \ + MCS8140_PCI_IOMISC_SIZE) +#define MCS8140_PCI_CFG_VIRT_BASE (MCS814X_IO_BASE - \ + MCS8140_PCI_CONFIG_SIZE)arch/arm/mach-mcs814x/include/mach/mcs814x.h
Quoted 10 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +9
-0+static unsigned long __pci_addr (struct pci_bus *bus, +unsigned int devfn,int offset) +{ +unsigned int busnr = bus->number; +unsigned int slot; + +/* we only support bus 0 */ +if (busnr !=0 ) +return 0 ;Why? A lot of devices have bridges on them and they should just work if you take out this check.
arch/arm/mach-mcs814x/include/mach/mcs814x.h
Quoted 4 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +4
-0+/* +* Trap out illegal values +*/ +BUG_ON (devfn >255 || busnr >255 || devfn >255 );You're checking devfn twice...
arch/arm/mach-mcs814x/include/mach/mcs814x.h
Quoted 8 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +8
-0+/* Scan 3 slots */ + slot =PCI_SLOT (devfn); +switch (slot) { +case 1 : +case 2 : +case 3 : +if (PCI_FUNC (devfn) >=4 ) +return 0 ;This also looks bogus. Why limit it to three devices?
Quoted 17 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +17
-0+static int mcs8140_pci_read_config (struct pci_bus *bus, +unsigned int devfn,int where, +int size,u32 *val) +{ +unsigned long v =0xFFFFFFFF ; +unsigned long addr =__pci_addr (bus, devfn, where); + +if (addr !=0 ) { +switch (size) { +case 1 : + v =__raw_readb (addr); +break ; +case 2 : + addr &= ~1 ; + v =__raw_readw (addr); +break ; +default :
Quoted 8 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h
Quoted 6 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +6
-0+ addr &= ~3 ; + v =__raw_readl (addr); +break ; + } + }else + v =0xffffffff ;This is just mmconfig, right? Don't we have a generic implementation for
that?
Quoted 11 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h
Quoted 8 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +7
-0+ +static struct resource io_mem = { + .name ="PCI I/O space" , + .start =MCS8140_PCI_HOST_BASE +MCS8140_PCI_IOMISC_BASE , + .end =MCS8140_PCI_HOST_BASE +MCS8140_PCI_IOMISC_BASE +SZ_64M , + .flags =IORESOURCE_IO , +};This is wrong:
MCS8140_PCI_HOST_BASEis an address inIORESOURCE_MEMspace. You probably also meanSZ_64Kinstead ofSZ_64M.
I will double check with the hardware manual, but I really think it is 64MBytes.
Quoted 19 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h
Quoted 10 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +9
-0+int __init pci_mcs8140_setup (int nr,struct pci_sys_data *sys) +{ +int ret =0 ; +u32 val; + +if (nr >0 ) +return 0 ; + + sys->mem_offset =MCS8140_PCI_IO_VIRT_BASE -MCS8140_PCI_IO_BASE ;Your address spaces are very confusing (or confused). So you have defined
#define MCS8140_PCI_IO_VIRT_BASE (MCS814X_IO_BASE - \ MCS8140_PCI_CONFIG_SIZE - \ MCS8140_PCI_IOMISC_SIZE) #define MCS8140_PCI_CFG_VIRT_BASE (MCS814X_IO_BASE - \ MCS8140_PCI_CONFIG_SIZE)
Quoted 7 lines
which means you
mem_offsetis (MCS814X_IO_BASE-MCS8140_PCI_CONFIG_SIZE-MCS8140_PCI_IOMISC_SIZE) - (MCS814X_IO_BASE-MCS8140_PCI_CONFIG_SIZE) which is (-MCS8140_PCI_IOMISC_SIZE), which in turn evaluates to -SZ_64M or0xfc000000. If that is the correct value, I'm sure it's just coincidence ;-)Quoted 1 line
+static int
__initmcs8140_map_irq(const structpci_dev*dev, u8 slot, u8
pin)
Quoted 45 lines
Quoted 6 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +6
-0+{ +int line =IRQ_PCI_INTA ; + +if (pin !=0 ) { +/* IRQ_PCIA - 22 */ +if (pin ==PCI_INTD )arch/arm/mach-mcs814x/include/mach/mcs814x.h
Quoted 10 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +10
-0+ line =IRQ_PCI_INTA + pin;/* IRQ_PCIA - 22 */ + else + line =IRQ_PCI_INTA + pin -1 ;/* IRQ_PCIA - 22 */ + } + +pr_info ("PCI: Map interrupt slot 0x%02x pin 0x%02x line 0x%02x\n" , + slot, pin, line); + +return line; +}This looks like a very unusual mapping. Maybe it's just wrong and that explains why you don't support child buses or additional slots?
In any case, you should use an "interrupt-map" in the device tree that describes how the IRQs are mapped to the slots. I think we have generic code to deal with that already.
Quoted 4 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +4
-0+static struct map_desc mcs8140_pci_io_desc[]__initdata = { + { + .virtual =MCS8140_PCI_CFG_VIRT_BASE , + .pfn =__phys_to_pfn (MCS8140_PCI_CFG_BASE ),arch/arm/mach-mcs814x/include/mach/mcs814x.h
Quoted 10 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +10
-0+ .length = MCS8140_PCI_CONFIG_SIZE, + .type = MT_DEVICE + }, + { + .virtual = MCS8140_PCI_IO_VIRT_BASE, + .pfn = __phys_to_pfn(MCS8140_PCI_IO_BASE), + .length = MCS8140_PCI_IOMISC_SIZE, + .type = MT_DEVICE + }, +};Please have a look at the latest patches from Rob Herring about mapping the I/O space. I don't think you need to map the config space early because you don't rely on a fixed location for that. Just use
of_iomap()to find that and store the pointer to the config space somewhere.
Quoted 8 lines
arch/arm/mach-mcs814x/include/mach/mcs814x.h
Quoted 1 line
arch/arm/mach-mcs814x/include/mach/mcs814x.h new file +1
-0+ pcibios_min_io =MCS8140_PCI_HOST_BASE ;Leave this one at the default of
0x1000.MCS8140_PCI_HOST_BASEis the address from the CPU's point of view, not from the bus. You just need to stay out of the range of possible legacy ISA devices.It's probably a good idea to keep the PCI support as a separate patch for reviewing purposes.
Good idea, I will do that. Note that none of the boards I have actually have PCI, so the code is just there in case someone needs it. I could also go along and remove it, since I cannot test it, which explains why there are so many inconsistencies with it.
Quoted 2 lines
Arnd
PATCH 1/8 ARM: support for Moschip MCS814x SoCs
Quoted 26 lines · Florian Fainelli
Quoted 16 lines · On Monday 16 July 2012 15:54:04 Arnd Bergmann wrote:
Quoted 14 lines · Florian Fainelli
arch/arm/mach-mcs814x/Kconfig new file +8
-0@@ -0,0 +1,11 @@ +if ARCH_MCS814X + +config MCS8140 + select CPU_ARM926T + bool + +menu "Moschip MCS8140 boards" +Quoted 8 lines
arch/arm/mach-mcs814x/Kconfig line 11
Quoted 3 lines
arch/arm/mach-mcs814x/Kconfig new file +3
-0+endmenu + +endifWhat values does the
Kconfigfile actually provide? I see that you are adding the boards here later, but I think it would be nice to just make the new platform a singleKconfigoption with no individual board selection.
Quoted 3 lines
I plan on adding support for MCS8142 later on, thus I thought it would be nice to be able to selectively compile board support for MCS8140 or some later chip.
But is there much difference between the two? How much code would actually get built for one chip but not the other? If all the differences can be run-time detected from the device tree, I think it's better to not have different compile-time options at all.
Quoted 7 lines
Quoted 7 lines
Platforms are now converting to the common clock framework in
drivers/clk. Mike Turquette as the subsystem maintainer can probably judge better whether we should still be allowing new platforms with their own implementation of clk, but my feeling is that you should use the subsystem instead and add a driver in a subdirectory ofdrivers/clkinstead of in the platform.
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
+void
__iomem*mcs814x_sysdbg_base;Does this have to be globally visible? I would recommend making it static.
Yes, since it is used both by
clock.candcommon.c
Ok. How about converting this to an global function in common.c that is called from clk_local_onoff_enable instead?
Quoted 18 lines
Quoted 9 lines
Quoted 9 lines
arch/arm/mach-mcs814x/Kconfig new file +9
-0+void __init mcs814x_map_io(void) +{ + iotable_init(mcs814x_io_desc, ARRAY_SIZE(mcs814x_io_desc)); + + mcs814x_sysdbg_base = ioremap(MCS814X_IO_START + MCS814X_SYSDBG, + MCS814X_SYSDBG_SIZE); + if (!mcs814x_sysdbg_base) + panic("unable to remap sysdbg base"); +}Quoted 8 lines
arch/arm/mach-mcs814x/Kconfig
Quoted 5 lines
arch/arm/mach-mcs814x/Kconfig new file +5
-0+ +void mcs814x_restart(char mode, const char *cmd) +{ + __raw_writel(~(1 << 31), mcs814x_sysdbg_base); +}You should generally avoid using
__raw_readletc. and instead use readl/write or readl_relaxed/writel_relaxed.
Quoted 1 line
Allright, even on an ARM926-EJS-based system?
Yes, there is no practical difference in the way they are defined at the moment, but the __raw_ versions are still wrong, you should really never be using them from driver code.
Quoted 27 lines
Quoted 1 line
arch/arm/mach-
Quoted 1 line
arch/arm/mach- renamed from arch/arm/mach-mcs814x/include/mach/cpu.h +0
-0
mcs814x/include/mach/cpu.hQuoted 16 lines
Quoted 16 lines
new file mode 100644
index 0000000..1ef3c4aarch/arm/mach-mcs814x/include/mach/cpu.h new file +11
-0@@ -0,0 +1,16 @@ +#ifndef __ASM_ARCH_CPU_H__ +#define __ASM_ARCH_CPU_H__ + +#include <asm/cputype.h> + +#define MCS8140_ID 0x41069260/* ARM926EJ-S */ +#define MCS814X_MASK 0xff0ffff0 + +#ifdef CONFIG_MCS8140 +/* Moschip MCS8140 is based on an ARM926EJ-S core */ +#define soc_is_mcs8140 () ((read_cpuid_id() & MCS814X_MASK) == MCS8140_ID)Quoted 8 lines
arch/arm/mach-mcs814x/include/mach/cpu.h line 16
Quoted 5 lines
arch/arm/mach-mcs814x/include/mach/cpu.h new file +5
-0+#else +#define soc_is_mcs8140 () (0) +#endif /* !CONFIG_MCS8140 */ + +#endif /* __ASM_ARCH_CPU_H__ */ Can you explain what this is used for? Are there other SoCs in the same platform that will get added later?
Quoted 1 line
Yes, that's the plan.
Ok. But why do you need to know the soc type? If it's only for the uncompress.h code, it should probably stay local to that file.
Quoted 9 lines
Quoted 7 lines
arch/arm/mach-mcs814x/include/mach/cpu.h
Quoted 5 lines
arch/arm/mach-mcs814x/include/mach/cpu.h new file +5
-0+/* IRQ controller register offset */ +#define MCS814X_IRQ_ICR 0x00 +#define MCS814X_IRQ_ISR 0x04 +#define MCS814X_IRQ_MASK 0x20 +#define MCS814X_IRQ_STS0 0x40I'm pretty sure these can be in
irq.cNot unless I switch to
MULTI_IRQ_HANDLER.
I think you should do that, too. Forgot to mention it.
Quoted 11 lines
Quoted 10 lines
arch/arm/mach-mcs814x/include/mach/cpu.h
Quoted 7 lines
arch/arm/mach-mcs814x/include/mach/cpu.h new file +7
-0+ +static struct resource io_mem = { + .name ="PCI I/O space" , + .start =MCS8140_PCI_HOST_BASE +MCS8140_PCI_IOMISC_BASE , + .end =MCS8140_PCI_HOST_BASE +MCS8140_PCI_IOMISC_BASE +SZ_64M , + .flags =IORESOURCE_IO , +};This is wrong:
MCS8140_PCI_HOST_BASEis an address inIORESOURCE_MEMspace. You probably also meanSZ_64Kinstead ofSZ_64M.
Quoted 2 lines
I will double check with the hardware manual, but I really think it is 64MBytes.
Are there any devices hardwired to your PCI bus that require more than a few bytes of I/O space? If not, I think it should be 64KB. No known add-on cards require more than that, and it would just waste virtual address space, and prevents us from using the new common PCI I/O space helpers.
Quoted 5 lines
Quoted 5 lines
Leave this one at the default of
0x1000.MCS8140_PCI_HOST_BASEis the address from the CPU's point of view, not from the bus. You just need to stay out of the range of possible legacy ISA devices.
Quoted 7 lines
Quoted 2 lines
It's probably a good idea to keep the PCI support as a separate patch for reviewing purposes.
Good idea, I will do that. Note that none of the boards I have actually have PCI, so the code is just there in case someone needs it. I could also go along and remove it, since I cannot test it, which explains why there are so many inconsistencies with it.
Fair enough. Best drop it for now then. The PCI code is currently undergoing some changes, and when someone wants to get this to work, they should can probably better start from scratch with an independent bus driver that will end up looking much simpler than what you have today.
Arnd
PATCH 1/8 ARM: support for Moschip MCS814x SoCs
Quoted 5 lines · On Tuesday 17 July 2012 13:07:23 Arnd Bergmann wrote:
Quoted 4 lines · Florian Fainelli
Quoted 3 lines · On Monday 16 July 2012 15:54:04 Arnd Bergmann wrote:
arch/arm/mach-
Quoted 1 line · Florian Fainelli
arch/arm/mach- renamed from arch/arm/mach-mcs814x/Kconfig +0
-0
mcs814x/Kconfig
Quoted 22 lines
Quoted 22 lines
Quoted 21 lines
Quoted 6 lines
new file mode 100644
index 0000000..c89422farch/arm/mach-mcs814x/Kconfig new file +1
-0@@ -0,0 +1,11 @@ +if ARCH_MCS814Xarch/arm/mach-mcs814x/Kconfig line 11
Quoted 10 lines
arch/arm/mach-mcs814x/Kconfig new file +10
-0+ +config MCS8140 + select CPU_ARM926T + bool + +menu "Moschip MCS8140 boards" + +endmenu + +endifWhat values does the
Kconfigfile actually provide? I see that you are adding the boards here later, but I think it would be nice to just make the new platform a singleKconfigoption with no individual board selection.
Quoted 1 line
Quoted 1 line
I plan on adding support for MCS8142 later on, thus I thought it would be
nice
Quoted 8 lines
Quoted 2 lines
to be able to selectively compile board support for MCS8140 or some later chip.
But is there much difference between the two? How much code would actually get built for one chip but not the other? If all the differences can be run-time detected from the device tree, I think it's better to not have different compile-time options at all.
The big difference between the two is actually the CPU core, for MCS8140 they used a genuine ARM926EJS and for MCS8142 they actually use a FA526 core.
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Platforms are now converting to the common clock framework in
drivers/clk.
Quoted 1 line
Quoted 1 line
Quoted 1 line
Mike Turquette as the subsystem maintainer can probably judge better
whether
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
we should still be allowing new platforms with their own implementation of clk, but my feeling is that you should use the subsystem instead and add a driver in a subdirectory of
drivers/clkinstead of in the platform.Quoted 1 line
+void
__iomem*mcs814x_sysdbg_base;Does this have to be globally visible? I would recommend making it
static.
Quoted 5 lines
Quoted 2 lines
Yes, since it is used both by
clock.candcommon.cOk. How about converting this to an global function in
common.cthat is called fromclk_local_onoff_enableinstead?
Sounds good.
Quoted 27 lines
Quoted 19 lines
Quoted 10 lines
Quoted 10 lines
arch/arm/mach-mcs814x/Kconfig new file +9
-0+void __init mcs814x_map_io(void) +{ + iotable_init(mcs814x_io_desc, ARRAY_SIZE(mcs814x_io_desc)); + + mcs814x_sysdbg_base = ioremap(MCS814X_IO_START + MCS814X_SYSDBG, + MCS814X_SYSDBG_SIZE); + if (!mcs814x_sysdbg_base) + panic("unable to remap sysdbg base"); +}Quoted 8 lines
arch/arm/mach-mcs814x/Kconfig
Quoted 5 lines
arch/arm/mach-mcs814x/Kconfig new file +5
-0+ +void mcs814x_restart(char mode, const char *cmd) +{ + __raw_writel(~(1 << 31), mcs814x_sysdbg_base); +}You should generally avoid using
__raw_readletc. and instead use readl/write or readl_relaxed/writel_relaxed.Quoted 1 line
Allright, even on an ARM926-EJS-based system?
Yes, there is no practical difference in the way they are defined at the moment, but the
__raw_versions are still wrong, you should really never be using them from driver code.Quoted 2 lines
Quoted 1 line
arch/arm/mach-
Quoted 1 line
arch/arm/mach- renamed from arch/arm/mach-mcs814x/include/mach/cpu.h +0
-0
mcs814x/include/mach/cpu.h
Quoted 16 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
new file mode 100644
index 0000000..1ef3c4aarch/arm/mach-mcs814x/include/mach/cpu.h new file +3
-0@@ -0,0 +1,16 @@ +#ifndef __ASM_ARCH_CPU_H__ +#define __ASM_ARCH_CPU_H__ +Quoted 8 lines
Quoted 8 lines
arch/arm/mach-mcs814x/include/mach/cpu.h
Quoted 8 lines
arch/arm/mach-mcs814x/include/mach/cpu.h new file +8
-0+#include <asm/cputype.h> + +#define MCS8140_ID 0x41069260/* ARM926EJ-S */ +#define MCS814X_MASK 0xff0ffff0 + +#ifdef CONFIG_MCS8140 +/* Moschip MCS8140 is based on an ARM926EJ-S core */ +#define soc_is_mcs8140 () ((read_cpuid_id() & MCS814X_MASK) ==
MCS8140_ID)
Quoted 25 lines
Quoted 10 lines
Quoted 8 lines
arch/arm/mach-mcs814x/include/mach/cpu.h line 16
Quoted 5 lines
arch/arm/mach-mcs814x/include/mach/cpu.h new file +5
-0+#else +#define soc_is_mcs8140 () (0) +#endif /* !CONFIG_MCS8140 */ + +#endif /* __ASM_ARCH_CPU_H__ */ Can you explain what this is used for? Are there other SoCs in the same platform that will get added later?
Yes, that's the plan.
Ok. But why do you need to know the soc type? If it's only for the
uncompress.hcode, it should probably stay local to that file.Quoted 8 lines
Quoted 7 lines
arch/arm/mach-mcs814x/include/mach/cpu.h
Quoted 5 lines
arch/arm/mach-mcs814x/include/mach/cpu.h new file +5
-0+/* IRQ controller register offset */ +#define MCS814X_IRQ_ICR 0x00 +#define MCS814X_IRQ_ISR 0x04 +#define MCS814X_IRQ_MASK 0x20 +#define MCS814X_IRQ_STS0 0x40I'm pretty sure these can be in
irq.c
Quoted 13 lines
Quoted 1 line
Not unless I switch to
MULTI_IRQ_HANDLER.I think you should do that, too. Forgot to mention it.
Quoted 9 lines
Quoted 9 lines
arch/arm/mach-mcs814x/include/mach/cpu.h
Quoted 7 lines
arch/arm/mach-mcs814x/include/mach/cpu.h new file +7
-0+ +static struct resource io_mem = { + .name ="PCI I/O space" , + .start =MCS8140_PCI_HOST_BASE +MCS8140_PCI_IOMISC_BASE , + .end =MCS8140_PCI_HOST_BASE +MCS8140_PCI_IOMISC_BASE +SZ_64M , + .flags =IORESOURCE_IO , +};This is wrong:
MCS8140_PCI_HOST_BASEis an address inIORESOURCE_MEM
space.
Quoted 9 lines
Quoted 4 lines
Quoted 1 line
You probably also mean
SZ_64Kinstead ofSZ_64M.I will double check with the hardware manual, but I really think it is 64MBytes.
Are there any devices hardwired to your PCI bus that require more than a few bytes of I/O space? If not, I think it should be 64KB. No known add-on cards require more than that, and it would just waste virtual address space, and prevents us from using the new common PCI I/O space helpers.
Ok.
Quoted 10 lines
Quoted 10 lines
Quoted 8 lines
Leave this one at the default of
0x1000.MCS8140_PCI_HOST_BASEis the address from the CPU's point of view, not from the bus. You just need to stay out of the range of possible legacy ISA devices.It's probably a good idea to keep the PCI support as a separate patch for reviewing purposes.
Good idea, I will do that. Note that none of the boards I have actually
have
Quoted 1 line
Quoted 1 line
PCI, so the code is just there in case someone needs it. I could also go
along
Quoted 1 line
Quoted 1 line
and remove it, since I cannot test it, which explains why there are so
many
Quoted 6 lines
Quoted 1 line
inconsistencies with it.
Fair enough. Best drop it for now then. The PCI code is currently undergoing some changes, and when someone wants to get this to work, they should can probably better start from scratch with an independent bus driver that will end up looking much simpler than what you have today.
Yeah, I like that :)
Quoted 2 lines
Arnd
PATCH 1/8 ARM: support for Moschip MCS814x SoCs
Quoted 10 lines · Florian Fainelli
Quoted 5 lines · On Tuesday 17 July 2012 13:07:23 Arnd Bergmann wrote:
But is there much difference between the two? How much code would actually get built for one chip but not the other? If all the differences can be run-time detected from the device tree, I think it's better to not have different compile-time options at all.
The big difference between the two is actually the CPU core, for MCS8140 they used a genuine ARM926EJS and for MCS8142 they actually use a FA526 core.
Ok, I see. That probably is enough difference to justify separate Kconfig statements, especially since building a combined ARMv4/v5 kernel has some overhead compared to supporting just one of the two.
Arnd
PATCH 1/8 ARM: support for Moschip MCS814x SoCs
In reply to Arnd BergmannLe Mon, 16 Jul 2012 15:54:04 +0000,
Arnd Bergmann <[email protected]> a ?crit :
Quoted 7 lines
arch/arm/mach-mcs814x/common.c line 97
Quoted 4 lines
arch/arm/mach-mcs814x/common.c new file +4
-0+void mcs814x_restart (char mode,const char *cmd) +{ +__raw_writel (~(1 <<31 ), mcs814x_sysdbg_base); +}You should generally avoid using
__raw_readletc. and instead use readl/write or readl_relaxed/writel_relaxed.
I thought that readl/writel and readl_relaxed/writel_relaxed were used for PCI-style access, for which these macros/functions do automatically a conversion from the CPU-endianness to the PCI-endianness (little-endian). Here of course, this the SoC is used little-endian, it will just work because readl/writel will not do any endianness conversion, but if we were on a big-endian machine?
My understanding until now was that __raw_readl/__raw_writel should be used for accesses with native endianness, but apparently, it's more subtle than this. Would you mind expanding a bit on this?
Best regards,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 1/8 ARM: support for Moschip MCS814x SoCs
Quoted 18 lines · Thomas Petazzoni
Le Mon, 16 Jul 2012 15:54:04 +0000,
Arnd Bergmann <[email protected]> a ?crit :Quoted 7 lines
arch/arm/mach-mcs814x/common.c line 97
Quoted 4 lines
arch/arm/mach-mcs814x/common.c new file +4
-0+void mcs814x_restart (char mode,const char *cmd) +{ +__raw_writel (~(1 <<31 ), mcs814x_sysdbg_base); +}You should generally avoid using
__raw_readletc. and instead use readl/write or readl_relaxed/writel_relaxed.I thought that readl/writel and readl_relaxed/writel_relaxed were used for PCI-style access, for which these macros/functions do automatically a conversion from the CPU-endianness to the PCI-endianness (little-endian). Here of course, this the SoC is used little-endian, it will just work because readl/writel will not do any endianness conversion, but if we were on a big-endian machine?
Quoted 3 lines
My understanding until now was that __raw_readl/__raw_writel should be used for accesses with native endianness, but apparently, it's more subtle than this. Would you mind expanding a bit on this?
The __raw_* versions are basically only valid if you access a memory buffer, such as a video framebuffer. They do the conversion of an __iomem pointer into something that can be accessed by the compiler.
The non-raw versions have fixed endianess, guarantee that the access is done atomically (could be byte-wise otherwise) and that all the necessary barriers are used to synchronize against DMA and out-of-order execution.
We don't actually have accessors that are CPU-endian and guarantee that you can access an MMIO register properly.
On powerpc, the convention is that readl/writel should only be used to access PCI, but that is for the enhanced error handling, not for endianess.
Arnd
PATCH 1/8 ARM: support for Moschip MCS814x SoCs
Hello,
Thanks a lot for those details.
Le Tue, 17 Jul 2012 13:12:06 +0000,
Arnd Bergmann <[email protected]> a ?crit :
Quoted 13 lines
Quoted 3 lines
My understanding until now was that __raw_readl/__raw_writel should be used for accesses with native endianness, but apparently, it's more subtle than this. Would you mind expanding a bit on this?
The __raw_* versions are basically only valid if you access a memory buffer, such as a video framebuffer. They do the conversion of an
__iomempointer into something that can be accessed by the compiler.The non-raw versions have fixed endianess, guarantee that the access is done atomically (could be byte-wise otherwise) and that all the necessary barriers are used to synchronize against DMA and out-of-order execution.
Quoted 6 lines
We don't actually have accessors that are CPU-endian and guarantee that you can access an MMIO register properly.
On powerpc, the convention is that readl/writel should only be used to access PCI, but that is for the enhanced error handling, not for endianess.
And then, on PowerPC, which accessors do you use to access SoC-peripherals that are not on the PCI bus?
For example, drivers/tty/serial/mpsc.c uses writel/readl, so a conversion to/from little-endian is done when writing/reading registers. Are those memory-mapped devices little-endian even though they are used on big-endian PowerPCs?
I apologize for the silly questions, but I'm trying to make some sense out of these numerous I/O and memory accessors.
Thanks,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 1/8 ARM: support for Moschip MCS814x SoCs
Quoted 2 lines · Thomas Petazzoni
And then, on PowerPC, which accessors do you use to access SoC-peripherals that are not on the PCI bus?
PowerPC has in_le32/out_le32 and variants of those, which unfortunately are not defined for most other architectures, so you cannot use them in portable code. They are the same as readl/writel, but without the PCI error handling.
Quoted 7 lines
For example,
drivers/tty/serial/mpsc.cuses writel/readl, so a conversion to/from little-endian is done when writing/reading registers. Are those memory-mapped devices little-endian even though they are used on big-endian PowerPCs?I apologize for the silly questions, but I'm trying to make some sense out of these numerous I/O and memory accessors.
All combinations of little/big endian CPUs and peripherals have been done in the past, including peripherals that switch their endianess dynamically when you change the mode of the CPU, and those that come with an extra register to add byte-swapping for operating systems that don't deal with it.
It's all a big mess and there is no good solution that anyone has managed to come with to cover all possibilities. My recommendation is generally to use the little-endian accessors when they work, and have your bus-specific or driver-specific wrapper around those when the endianess is not always the same.
Arnd
PATCH 1/8 ARM: support for Moschip MCS814x SoCs
In reply to Florian Fainelliarch/arm/mach-mcs814x/clock.c
Quoted 1 line · Florian Fainelli
arch/arm/mach-mcs814x/clock.c +0
-0
As mentioned by other reviewers, move this to the new common clock framework. I just migrated the Integrator, Nomadik and U300 for the v3.7 merge window, we need to get rid of these implementations, not make more of them.
arch/arm/mach-mcs814x/common.c
Quoted 1 line
arch/arm/mach-mcs814x/common.c +0
-0
Usually this kind of file is called "core.c".
Quoted 7 lines
arch/arm/mach-mcs814x/common.c +7
-0+void __init mcs814x_init_machine (void ) +{ +u32 bs2, cpu_mode; +int gpio; + + bs2 =__raw_readl (mcs814x_sysdbg_base +SYSDBG_BS2 ); + cpu_mode = (bs2 >>CPU_MODE_SHIFT ) &CPU_MODE_MASK ;
arch/arm/mach-mcs814x/common.c line 82
Quoted 10 lines
arch/arm/mach-mcs814x/common.c +10
-0+ +pr_info ("CPU mode: %s\n" , cpu_modes[cpu_mode].name); + +/* request the gpios since the pins are muxed for functionnality */ +for (gpio = cpu_modes[cpu_mode].gpio_start; + gpio == cpu_modes[cpu_mode].gpio_end; gpio++) { +if (gpio !=-1 ) +gpio_request (gpio, cpu_modes[cpu_mode].name); + } +}
What is this? It is looking very suspiciouly much like a pin multiplexer, which means it should have a driver in drivers/pinctrl/pinctrl-foo.c not in arch/arm/*.
I do understand it is just a small hack to make things work, but I fear it is going to grow and then it sets a bad example.
This version looks like switching some I2S, GPIO and UART and that's all, but I highly suspect that is not the whole story, is it? Better to get it in right shape from the start.
Quoted 5 lines
arch/arm/mach-mcs814x/irq.c new file +0
-0
(...)
arch/arm/mach-mcs814x/irq.c line 43
Quoted 2 lines
arch/arm/mach-mcs814x/irq.c new file +2
-0+/* Clear all interrupts */ +__raw_writel (0xffffffff , base +MCS814X_IRQ_ICR );
Consider writel_relaxed()
Quoted 25 lines
arch/arm/mach-mcs814x/include/mach/entry-macro.S new file +19
-0@@ -0,0 +1,29 @@ +#include <mach/mcs814x.h> + .macro disable_fiq + .endm + + .macro arch_ret_to_user, tmp1, tmp2 + .endm + + .macro get_irqnr_preamble, base, tmp + ldr \base, =mcs814x_intc_base@ base virtual address of INTC + ldr \base, [\base] + .endm + + .macro get_irqnr_and_base, irqnr, irqstat, base, tmp + mov \tmp, #MCS814X_IRQ_STS0 @ load tmp with STS0 register offset + ldr \irqstat, [\base, \tmp] @ load value at base + tmp + tst \irqstat, \irqstat @ test if no active IRQ's + beq 1002f @ if no active irqs return with status 0 + mov \irqnr, #0 @ start from irq zero + mov \tmp, #1 @ the mask initially 1
arch/arm/mach-mcs814x/include/mach/entry-macro.S line 29
Quoted 10 lines
arch/arm/mach-mcs814x/include/mach/entry-macro.S new file +10
-0+1001: + tst \irqstat, \tmp @ and with mask + addeq \irqnr, \irqnr, #1 @ if zero then add one to nr + moveq \tmp, \tmp, lsl #1 @ shift mask one to left + beq 1001b @ if zero then loop again + mov \irqstat, \tmp @ save the return mask + mov \tmp, #MCS814X_IRQ_STS0 @ load tmp with ICR offset + str \irqstat, [\base, \tmp] @ clear irq with selected mask +1002: + .endm
Don't do this. Delete this file.
Let your platform select MULTI_IRQ_HANDLER
Then let your platform MACHINE_START (or DT_MACHINE_START)
have a .handle_irq member, calling a function from your interrupt controller driver to handle the IRQs.
Add some
asmlinkage void __exception_irq_entry foo_handle_irq(struct pt_regs *regs)
And rewrite the entry handler in plain C.
Refer to for example the rewrite I do of the FPGA IRQ controller in commit 3108e6ab21a9b9dbd88f0b2ff99f73e95b8b1580 or directly to arch/arm/plat-versatile/fpga-irq.c orarch/arm/common/vic.c for an example.
arch/arm/mach-mcs814x/timer.c
Quoted 1 line
arch/arm/mach-mcs814x/timer.c +0
-0
A timer driver not #including <linux/clockchips.h> and <linux/clocksource.h> is a real bad idea.
(...)
Quoted 8 lines
arch/arm/mach-mcs814x/timer.c +8
-0+static inline unsigned long ticks2usecs (u32 x) +{ +return x / (clock_rate /1000000 ); +} + +/* +* Returns number of ms since last clock interrupt. Note that interrupts +* will have been disabled by do_gettimeoffset()
arch/arm/mach-mcs814x/timer.c line 49
Quoted 10 lines
arch/arm/mach-mcs814x/timer.c +10
-0+*/ +static unsigned long mcs814x_gettimeoffset (void ) +{ +u32 ticks =__raw_readl (mcs814x_timer_base +TIMER_VAL ); + +if (ticks < last_reload) +return ticks2usecs (ticks + (u32)(0xffffffff - last_reload)); +else +return ticks2usecs (ticks - last_reload); +}
This is not looking good. Don't handle ticks -> usec conversion in the driver.
arch/arm/mach-mcs814x/timer.c line 63
Quoted 12 lines
arch/arm/mach-mcs814x/timer.c +12
-0+static irqreturn_t mcs814x_timer_interrupt (int irq,void *dev_id) +{ +u32 count =__raw_readl (mcs814x_timer_base +TIMER_VAL ); + +/* take into account delay up to this moment */ + last_reload = count + timer_correct + timer_reload_value; + +if (last_reload < timer_reload_value) + last_reload = timer_reload_value; +else if (timer_correct ==0 ) + timer_correct =__raw_readl (mcs814x_timer_base +TIMER_VAL ) - + count;
Don't do this. Let the timer infrastructure take care of these things.
arch/arm/mach-mcs814x/timer.c line 67
Quoted 3 lines
arch/arm/mach-mcs814x/timer.c +3
-0+__raw_writel (last_reload, mcs814x_timer_base +TIMER_VAL ); + +timer_tick ();
Only archaic and bad example platforms call timer_tick() directly. Use the clockevent API.
Quoted 23 lines
arch/arm/mach-mcs814x/timer.c +23
-0+ +return IRQ_HANDLED ; +} + +static struct irqaction mcs814x_timer_irq = { + .name ="mcs814x-timer" , + .flags =IRQF_DISABLED |IRQF_TIMER |IRQF_IRQPOLL , + .handler = mcs814x_timer_interrupt, +}; + +static struct of_device_id mcs814x_timer_ids[] = { + { .compatible ="moschip,mcs814x-timer" }, + {/* sentinel */ }, +}; + +static void __init mcs814x_of_timer_init (void ) +{ +struct device_node *np; +const unsigned int *intspec; + + np =of_find_matching_node (NULL , mcs814x_timer_ids); +if (!np) +panic ("unable to find compatible timer node in dtb" );
arch/arm/mach-mcs814x/timer.c line 100
Quoted 10 lines
arch/arm/mach-mcs814x/timer.c +10
-0+ + mcs814x_timer_base =of_iomap (np,0 ); +if (!mcs814x_timer_base) +panic ("unable to remap timer cpu registers" ); + + intspec =of_get_property (np,"interrupts" ,NULL ); +if (!intspec) +panic ("no interrupts property for timer" ); + + mcs814x_timer_irq.irq =be32_to_cpup (intspec);
Why are you getting and converting this from bigendian?
What is wrong with using irq_of_parse_and_map(np, 0) for this, this just looks dangerous.
arch/arm/mach-mcs814x/timer.c line 109
Quoted 9 lines
arch/arm/mach-mcs814x/timer.c +9
-0+} + +static void __init mcs814x_timer_init (void ) +{ +struct clk *clk; + + clk =clk_get_sys ("timer0" ,NULL ); +if (IS_ERR_OR_NULL (clk)) +panic ("unable to get timer0 clock" );
clk_prepare_enable() is needed at this point.
arch/arm/mach-mcs814x/timer.c line 112
Quoted 3 lines
arch/arm/mach-mcs814x/timer.c +3
-0+ + clock_rate =clk_get_rate (clk); +clk_put (clk);
Don't put the clock here, you're using it, perpetually. If you put() it the clock framework can disable it at as unused.
Quoted 11 lines
arch/arm/mach-mcs814x/timer.c +11
-0+ +mcs814x_of_timer_init (); + +pr_info ("Timer frequency: %d (kHz)\n" , clock_rate /1000 ); + + timer_reload_value =0xffffffff - (clock_rate /HZ ); + +/* disable timer */ +__raw_writel (0 , mcs814x_timer_base +TIMER_CTL ); +__raw_writel (timer_reload_value, mcs814x_timer_base +TIMER_VAL ); + last_reload = timer_reload_value;
arch/arm/mach-mcs814x/timer.c line 133
Quoted 10 lines
arch/arm/mach-mcs814x/timer.c +10
-0+ +setup_irq (mcs814x_timer_irq.irq, &mcs814x_timer_irq); +/* enable timer, stop timer in debug mode */ +__raw_writel (0x03 , mcs814x_timer_base +TIMER_CTL ); +} + +struct sys_timer mcs814x_timer = { + .init = mcs814x_timer_init, + .offset = mcs814x_gettimeoffset, +};
No .offset and rewrite this to register a clock source+clock event and use that instead.
Please look at arch/arm/common/timer-sp.c for a good example of how a timer driver should look.
You will feel it's much more elegant afterwards :-)
What might be complicated is that it appears you have only one single timer in your system, is that reallty the case? Usually Linux fires one timer to just "run free" to be used as cycle counter (clock source) and another one to "shoot events" (clock event)
I've never seen one and the same timer being used for both clock source and clock events but if you really have only one timer I think that is also feasible, but will need some serious hacking.
Yours,
Linus Walleij
PATCH 2/8 ARM: MCS814x: add Device Tree based MCS8140 board support
In reply to Florian FainelliThis patch adds a generic MCS8140-based device tree registration board along with the corresponding mcs8140.dtsi file.
--- arch/arm/boot/dts/mcs8140.dtsi | 207 ++++++++++++++++++++++++++++++ arch/arm/mach-mcs814x/board-mcs8140-dt.c | 44 +++++++ 2 files changed, 251 insertions(+) create mode 100644 arch/arm/boot/dts/mcs8140.dtsi create mode 100644 arch/arm/mach-mcs814x/board-mcs8140-dt.c
arch/arm/boot/dts/mcs8140.dtsi new file +207 -0
@@ -0,0 +1,207 @@ +/* + * mcs8140.dtsi - Device Tree Include file for Moschip MCS8140 family SoC + * + * Copyright (C) 2012, Florian Fainelli <[email protected]> + * + * Licensed under GPLv2. + */ + +/include/ "skeleton.dtsi" + +/ { + model = "Moschip MCS8140 family SoC"; + compatible = "moschip,mcs8140"; + interrupt-parent = <&intc>; + + aliases { + serial0 = &uart0; + eth0 = ð0; + }; + + cpus { + cpu at 0 { + compatible = "arm,arm926ejs"; + }; + }; + + ahb { + compatible = "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + vci { + compatible = "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + eth0: ethernet at 40084000 { + compatible = "moschip,nuport-mac"; + reg = <0x40084000 0xd8 // mac + 0x40080000 0x58>; // dma channels + interrupts = <4 5 29>; /* tx, rx, link */ + nuport-mac,buffer-shifting; + nuport-mac,link-activity = <0>; + }; + + tso at 40088000 { + reg = <0x40088000 0x1c>; + interrupts = <7>; + }; + + i2s at 4008c000 { + compatible = "moschip,mcs814x-i2s"; + reg = <0x4008c000 0x18>; + interrupts = <8>; + }; + + ipsec at 40094000 { + compatible = "moschip,mcs814x-ipsec"; + reg = <0x40094000 0x1d8>; + interrupts = <16>; + }; + + rng at 4009c000 { + compatible = "moschip,mcs814x-rng"; + reg = <0x4009c000 0x8>; + }; + + memc at 400a8000 { + reg = <0x400a8000 0x58>; + }; + + list-proc at 400ac0c0 { + reg = <0x400ac0c0 0x38>; + interrupts = <19 27>; // done, error + }; + + pci at 400b0000 { + compatible = "moschip,mcs814x-pci"; + reg = <0x400b0000 0x44 // PCI master + 0x400d8000 0xe4>; // EEPROM emulator + interrupts = <25>; // abort interrupt + status = "disabled"; + #address-cells = <3>; + #size-cells = <2>; + + ranges = <0x01000000 0 0x80000000 0x80000000 0 0x04000000 // IO + 0x42000000 0 0x90000000 0x90000000 0 0x20000000 // non-prefetch + 0x02000000 0 0xb0000000 0xb0000000 0 0x10000000>; // prefecth + + #interrupt-cells = <1>; + interrupt-map-mask = <>; + interrupt-map = <0 0 0 1 &intc 22 0 + 0 0 0 2 &intc 23 0 + 0 0 0 3 &intc 24 0 + 0 0 0 4 &intc 26 0>; + }; + + gpio: gpio at 400d0000 { + compatible = "moschip,mcs814x-gpio"; + reg = <0x400d0000 0x670>; + interrupts = <10>; + #gpio-cells = <2>; + gpio-controller; + num-gpios = <20>; + }; + + eepio: gpio at 400d4000 { + compatible = "moschip,mcs814x-gpio"; + reg = <0x400d4000 0x470>; + #gpio-cells = <2>; + gpio-controller; + num-gpios = <4>; + }; + + uart0: serial at 400dc000 { + compatible = "ns16550"; + reg = <0x400dc000 0x20>; + clock-frequency = <50000000>; + reg-shift = <2>; + interrupts = <21>; + status = "okay"; + }; + + intc: interrupt-controller at 400e4000 { + #interrupt-cells = <1>; + compatible = "moschip,mcs814x-intc"; + interrupt-controller; + interrupt-parent; + reg = <0x400e4000 0x48>; + }; + + m2m at 400e8000 { + reg = <0x400e8000 0x24>; + interrupts = <17>; + }; + + eth-filters at 400ec000 { + reg = <0x400ec000 0x80>; + }; + + timer: timer at 400f800c { + compatible = "moschip,mcs814x-timer"; + interrupts = <0>; + reg = <0x400f800c 0x8>; + }; + + watchdog at 400f8014 { + compatible = "moschip,mcs814x-wdt"; + reg = <0x400f8014 0x8>; + }; + + adc { + compatible = "simple-bus"; + #address-cells = <2>; + #size-cells = <1>; + // 8 64MB chip-selects + ranges = <0 0 0x00000000 0x4000000 // sdram + 1 0 0x04000000 0x4000000 // sdram + 2 0 0x08000000 0x4000000 // reserved + 3 0 0x0c000000 0x4000000 // flash/localbus + 4 0 0x10000000 0x4000000 // flash/localbus + 5 0 0x14000000 0x4000000 // flash/localbus + 6 0 0x18000000 0x4000000 // flash/localbus + 7 0 0x1c000000 0x4000000>; // flash/localbus + + sdram: memory at 0,0 { + reg = <0 0 0>; + }; + + nor: flash at 7,0 { + reg = <7 0 0x4000000>; + compatible = "cfi-flash"; + bank-width = <1>; // 8-bit external flash + #address-cells = <1>; + #size-cells = <1>; + }; + }; + + usb0: ehci at 400fc000 { + compatible = "moschip,mcs814x-ehci", "usb-ehci"; + reg = <0x400fc000 0x74>; + interrupts = <2>; + }; + + usb1: ohci at 400fd000 { + compatible = "moschip,mcs814x-ohci", "ohci-le"; + reg = <0x400fd000 0x74>; + interrupts = <11>; + }; + + usb2: ohci at 400fe000 { + compatible = "moschip,mcs814x-ohci", "ohci-le"; + reg = <0x400fe000 0x74>; + interrupts = <12>; + }; + + usb3: otg at 400ff000 { + compatible = "moschip,msc814x-otg", "usb-otg"; + reg = <0x400ff000 0x1000>; + interrupts = <13>; + }; + }; + + }; +};
arch/arm/mach-mcs814x/board-mcs8140-dt.c new file +44 -0
44 lines not on this page · raw message
Signature · 1 line
1.7.10.4
PATCH 2/8 ARM: MCS814x: add Device Tree based MCS8140 board support
arch/arm/boot/dts/mcs8140.dtsi line 124
Quoted 9 lines · Florian Fainelli
arch/arm/boot/dts/mcs8140.dtsi new file +9
-0+ + uart0: serial at 400dc000 { + compatible = "ns16550"; + reg = <0x400dc000 0x20>; + clock-frequency = <50000000>; + reg-shift = <2>; + interrupts = <21>; + status = "okay"; + };
We often mark stuff like the uart as status="disabled" in the .dtsi file and only enable it in the board specific .dts file when it's actually connected. For components that are always present and usable, that's of course not necessary.
Quoted 17 lines
arch/arm/boot/dts/mcs8140.dtsi new file +17
-0+ + adc { + compatible = "simple-bus"; + #address-cells = <2>; + #size-cells = <1>; + // 8 64MB chip-selects + ranges = <0 0 0x00000000 0x4000000 // sdram + 1 0 0x04000000 0x4000000 // sdram + 2 0 0x08000000 0x4000000 // reserved + 3 0 0x0c000000 0x4000000 // flash/localbus + 4 0 0x10000000 0x4000000 // flash/localbus + 5 0 0x14000000 0x4000000 // flash/localbus + 6 0 0x18000000 0x4000000 // flash/localbus + 7 0 0x1c000000 0x4000000>; // flash/localbus + + sdram: memory at 0,0 { + reg = <0 0 0>;
arch/arm/boot/dts/mcs8140.dtsi line 179
Quoted 10 lines
arch/arm/boot/dts/mcs8140.dtsi new file +10
-0+ }; + + nor: flash at 7,0 { + reg = <7 0 0x4000000>; + compatible = "cfi-flash"; + bank-width = <1>; // 8-bit external flash + #address-cells = <1>; + #size-cells = <1>; + }; + };
Nice representation of the external buses. It does seem however that at least the nor flash entry is board specific and should be moved into the board .dts file.
I would probably do the same for the memory node, but that one is less obvious as it seems that there is not much choice here.
Quoted 13 lines
arch/arm/boot/dts/mcs8140.dtsi new file +13
-0+ usb0: ehci at 400fc000 { + compatible = "moschip,mcs814x-ehci", "usb-ehci"; + reg = <0x400fc000 0x74>; + interrupts = <2>; + }; + + usb1: ohci at 400fd000 { + compatible = "moschip,mcs814x-ohci", "ohci-le"; + reg = <0x400fd000 0x74>; + interrupts = <11>; + }; + + usb2: ohci at 400fe000 {
arch/arm/boot/dts/mcs8140.dtsi line 203
Quoted 10 lines
arch/arm/boot/dts/mcs8140.dtsi new file +10
-0+ compatible = "moschip,mcs814x-ohci", "ohci-le"; + reg = <0x400fe000 0x74>; + interrupts = <12>; + }; + + usb3: otg at 400ff000 { + compatible = "moschip,msc814x-otg", "usb-otg"; + reg = <0x400ff000 0x1000>; + interrupts = <13>; + };
same comment as for the uart, I would mark these as disabled and only enable the ones that are connected on a give board.
Quoted 12 lines
arch/arm/mach-mcs814x/board-mcs8140-dt.c new file +12
-0+ +static void __init mcs814x_dt_device_init (void ) +{ +of_platform_populate (NULL , of_default_bus_match_table,NULL ,NULL ); +mcs814x_init_machine (); +} + +static const char *mcs8140_dt_board_compat[]__initdata = { +"moschip,mcs8140" , +NULL ,/* sentinel */ +}; +
arch/arm/mach-mcs814x/board-mcs8140-dt.c line 43
Quoted 10 lines
arch/arm/mach-mcs814x/board-mcs8140-dt.c new file +10
-0+DT_MACHINE_START (mcs8140_dt,"Moschip MCS8140 board" ) +/* Maintainer: Florian Fainelli <[email protected]> */ + .timer = &mcs814x_timer, + .map_io = mcs814x_map_io, + .init_early = mcs814x_clk_init, + .init_irq = mcs814x_of_irq_init, + .init_machine = mcs814x_dt_device_init, + .restart = mcs814x_restart, + .dt_compat = mcs8140_dt_board_compat, +MACHINE_END
Not much to see here. Just move this into the common.c file. There is no need to have a separate board file when all boards use the same one.
Arnd
PATCH 2/8 ARM: MCS814x: add Device Tree based MCS8140 board support
Quoted 16 lines · On Tuesday 17 July 2012 13:19:43 Arnd Bergmann wrote:
arch/arm/boot/dts/mcs8140.dtsi line 124
Quoted 9 lines · Florian Fainelli
arch/arm/boot/dts/mcs8140.dtsi new file +9
-0+ + uart0: serial at 400dc000 { + compatible = "ns16550"; + reg = <0x400dc000 0x20>; + clock-frequency = <50000000>; + reg-shift = <2>; + interrupts = <21>; + status = "okay"; + };We often mark stuff like the uart as status="disabled" in the .dtsi file and only enable it in the board specific .dts file when it's actually connected. For components that are always present and usable, that's of course not necessary.
Ok, I thought it could be handy to have the uart enabled by default to avoid mixing with the status property, I don't mind setting it to "disabled" by default.
Quoted 11 lines
arch/arm/boot/dts/mcs8140.dtsi
Quoted 11 lines
arch/arm/boot/dts/mcs8140.dtsi new file +10
-0+ + adc { + compatible = "simple-bus"; + #address-cells = <2>; + #size-cells = <1>; + // 8 64MB chip-selects + ranges = <0 0 0x00000000 0x4000000 // sdram + 1 0 0x04000000 0x4000000 // sdram + 2 0 0x08000000 0x4000000 // reserved + 3 0 0x0c000000 0x4000000 //
flash/localbus
Quoted 1 line
Review
Quoted 1 line
(quoted diff) +1
-0+ 4 0 0x10000000 0x4000000 //
flash/localbus
Quoted 1 line
Review
Quoted 1 line
(quoted diff) +1
-0+ 5 0 0x14000000 0x4000000 //
flash/localbus
Quoted 1 line
Review
Quoted 1 line
(quoted diff) +1
-0+ 6 0 0x18000000 0x4000000 //
flash/localbus
Quoted 1 line
Review
Quoted 1 line
(quoted diff) +1
-0+ 7 0 0x1c000000 0x4000000>; //
flash/localbus
Quoted 9 lines
arch/arm/boot/dts/mcs8140.dtsi
Quoted 9 lines
arch/arm/boot/dts/mcs8140.dtsi new file +9
-0+ + sdram: memory at 0,0 { + reg = <0 0 0>; + }; + + nor: flash at 7,0 { + reg = <7 0 0x4000000>; + compatible = "cfi-flash"; + bank-width = <1>; // 8-bit external
flash
Quoted 8 lines
arch/arm/boot/dts/mcs8140.dtsi line 51
Quoted 4 lines
arch/arm/boot/dts/mcs8140.dtsi new file +4
-0+ #address-cells = <1>; + #size-cells = <1>; + }; + };Nice representation of the external buses. It does seem however that at least the nor flash entry is board specific and should be moved into the board .dts file.
In fact, MCS8140 only supports 8-bit CFI Flash chips, so this really is the common point of all MCS8140-based boards. As you can see in the following board-specific DTS patches, only the partition layout is different.
Quoted 2 lines
I would probably do the same for the memory node, but that one is less obvious as it seems that there is not much choice here.
The memory node is also overridden by the board-specific DTS files in subsequent patches.
Quoted 45 lines
Quoted 14 lines
arch/arm/boot/dts/mcs8140.dtsi new file +13
-0+ usb0: ehci at 400fc000 { + compatible = "moschip,mcs814x-ehci", "usb-ehci"; + reg = <0x400fc000 0x74>; + interrupts = <2>; + }; + + usb1: ohci at 400fd000 { + compatible = "moschip,mcs814x-ohci", "ohci-le"; + reg = <0x400fd000 0x74>; + interrupts = <11>; + }; + + usb2: ohci at 400fe000 {arch/arm/boot/dts/mcs8140.dtsi line 203
Quoted 10 lines
arch/arm/boot/dts/mcs8140.dtsi new file +10
-0+ compatible = "moschip,mcs814x-ohci", "ohci-le"; + reg = <0x400fe000 0x74>; + interrupts = <12>; + }; + + usb3: otg at 400ff000 { + compatible = "moschip,msc814x-otg", "usb-otg"; + reg = <0x400ff000 0x1000>; + interrupts = <13>; + };same comment as for the uart, I would mark these as disabled and only enable the ones that are connected on a give board.
Quoted 17 lines
arch/arm/mach-mcs814x/board-mcs8140-dt.c new file +17
-0+ +static void __init mcs814x_dt_device_init (void ) +{ +of_platform_populate (NULL , of_default_bus_match_table,NULL ,NULL ); +mcs814x_init_machine (); +} + +static const char *mcs8140_dt_board_compat[]__initdata = { +"moschip,mcs8140" , +NULL ,/* sentinel */ +}; + +DT_MACHINE_START (mcs8140_dt,"Moschip MCS8140 board" ) +/* Maintainer: Florian Fainelli <[email protected]> */ + .timer = &mcs814x_timer, + .map_io = mcs814x_map_io, + .init_early = mcs814x_clk_init,
Quoted 8 lines
arch/arm/mach-mcs814x/board-mcs8140-dt.c line 43
Quoted 5 lines
arch/arm/mach-mcs814x/board-mcs8140-dt.c new file +5
-0+ .init_irq = mcs814x_of_irq_init, + .init_machine = mcs814x_dt_device_init, + .restart = mcs814x_restart, + .dt_compat = mcs8140_dt_board_compat, +MACHINE_END Not much to see here. Just move this into the
common.cfile. There is no need to have a separate board file when all boards use the same one.
Allright.
Quoted 2 lines
Arnd
PATCH 2/8 ARM: MCS814x: add Device Tree based MCS8140 board support
Quoted 40 lines · Florian Fainelli
Quoted 11 lines · On Tuesday 17 July 2012 13:19:43 Arnd Bergmann wrote:
arch/arm/boot/dts/mcs8140.dtsi
Quoted 9 lines · Florian Fainelli
arch/arm/boot/dts/mcs8140.dtsi new file +9
-0+ adc { + compatible = "simple-bus"; + #address-cells = <2>; + #size-cells = <1>; + // 8 64MB chip-selects + ranges = <0 0 0x00000000 0x4000000 // sdram + 1 0 0x04000000 0x4000000 // sdram + 2 0 0x08000000 0x4000000 // reserved + 3 0 0x0c000000 0x4000000 //flash/localbus
Quoted 1 line
Review
Quoted 1 line
(quoted diff) +1
-0+ 4 0 0x10000000 0x4000000 //flash/localbus
Quoted 1 line
Review
Quoted 1 line
(quoted diff) +1
-0+ 5 0 0x14000000 0x4000000 //flash/localbus
Quoted 1 line
Review
Quoted 1 line
(quoted diff) +1
-0+ 6 0 0x18000000 0x4000000 //flash/localbus
Quoted 1 line
Review
Quoted 1 line
(quoted diff) +1
-0+ 7 0 0x1c000000 0x4000000>; //flash/localbus
Quoted 9 lines
arch/arm/boot/dts/mcs8140.dtsi
Quoted 9 lines
arch/arm/boot/dts/mcs8140.dtsi new file +9
-0+ + sdram: memory at 0,0 { + reg = <0 0 0>; + }; + + nor: flash at 7,0 { + reg = <7 0 0x4000000>; + compatible = "cfi-flash"; + bank-width = <1>; // 8-bit externalflash
Quoted 8 lines
arch/arm/boot/dts/mcs8140.dtsi line 51
Quoted 4 lines
arch/arm/boot/dts/mcs8140.dtsi new file +4
-0+ #address-cells = <1>; + #size-cells = <1>; + }; + };Nice representation of the external buses. It does seem however that at least the nor flash entry is board specific and should be moved into the board .dts file.
Quoted 3 lines
In fact, MCS8140 only supports 8-bit CFI Flash chips, so this really is the common point of all MCS8140-based boards. As you can see in the following board-specific DTS patches, only the partition layout is different.
But is the flash always connected to bank 7? It looks like you could easily have a NIC on that one and the flash on a different bank.
Arnd
PATCH 2/8 ARM: MCS814x: add Device Tree based MCS8140 board support
Quoted 41 lines · On Tuesday 17 July 2012 13:53:13 Arnd Bergmann wrote:
Quoted 40 lines · Florian Fainelli
Quoted 11 lines · On Tuesday 17 July 2012 13:19:43 Arnd Bergmann wrote:
arch/arm/boot/dts/mcs8140.dtsi
Quoted 9 lines · Florian Fainelli
arch/arm/boot/dts/mcs8140.dtsi new file +9
-0+ adc { + compatible = "simple-bus"; + #address-cells = <2>; + #size-cells = <1>; + // 8 64MB chip-selects + ranges = <0 0 0x00000000 0x4000000 // sdram + 1 0 0x04000000 0x4000000 // sdram + 2 0 0x08000000 0x4000000 // reserved + 3 0 0x0c000000 0x4000000 //flash/localbus
Quoted 1 line
Review
Quoted 1 line
(quoted diff) +1
-0+ 4 0 0x10000000 0x4000000 //flash/localbus
Quoted 1 line
Review
Quoted 1 line
(quoted diff) +1
-0+ 5 0 0x14000000 0x4000000 //flash/localbus
Quoted 1 line
Review
Quoted 1 line
(quoted diff) +1
-0+ 6 0 0x18000000 0x4000000 //flash/localbus
Quoted 1 line
Review
Quoted 1 line
(quoted diff) +1
-0+ 7 0 0x1c000000 0x4000000>; //flash/localbus
Quoted 9 lines
arch/arm/boot/dts/mcs8140.dtsi
Quoted 9 lines
arch/arm/boot/dts/mcs8140.dtsi new file +9
-0+ + sdram: memory at 0,0 { + reg = <0 0 0>; + }; + + nor: flash at 7,0 { + reg = <7 0 0x4000000>; + compatible = "cfi-flash"; + bank-width = <1>; // 8-bit externalflash
Quoted 8 lines
arch/arm/boot/dts/mcs8140.dtsi line 51
Quoted 4 lines
arch/arm/boot/dts/mcs8140.dtsi new file +4
-0+ #address-cells = <1>; + #size-cells = <1>; + }; + };Nice representation of the external buses. It does seem however that at least the nor flash entry is board specific and should be moved into the board .dts file.
Quoted 1 line
Quoted 1 line
In fact, MCS8140 only supports 8-bit CFI Flash chips, so this really is
the
Quoted 4 lines
Quoted 2 lines
common point of all MCS8140-based boards. As you can see in the following board-specific DTS patches, only the partition layout is different.
But is the flash always connected to bank 7? It looks like you could easily
have
Quoted 1 line
a NIC on that one and the flash on a different bank.
In fact, the only constraint is that bank7 is the only one which can be used for an external boot flash. I do not have any problem moving this to the per- board DTS file.
--
Florian
PATCH 3/8 ARM: MCS814x: add Device Tree bindings documentation
In reply to Florian FainelliThis patch adds the device tree bindings documentation for the basic Moschip MCS814x bindings that we support:
- soc
- interrupt controller
- timer
- pci controller
--- .../devicetree/bindings/arm/mcs814x/mcs814x-intc.txt | 18 ++++++++++++++++++ .../devicetree/bindings/arm/mcs814x/mcs814x-pci.txt | 16 ++++++++++++++++ .../bindings/arm/mcs814x/mcs814x-timer.txt | 16 ++++++++++++++++ .../devicetree/bindings/arm/mcs814x/mcs814x.txt | 13 +++++++++++++ .../devicetree/bindings/vendor-prefixes.txt | 1 + 5 files changed, 64 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/mcs814x/mcs814x-intc.txt create mode 100644 Documentation/devicetree/bindings/arm/mcs814x/mcs814x-pci.txt create mode 100644 Documentation/devicetree/bindings/arm/mcs814x/mcs814x-timer.txt create mode 100644 Documentation/devicetree/bindings/arm/mcs814x/mcs814x.txt
Documentation/devicetree/bindings/arm/mcs814x/mcs814x-intc.txt new file +18 -0
@@ -0,0 +1,18 @@ +Moschip MCS814x interrupt controller bindings +---------------------------------------------- + +Required properties: +- compatible: should be "moschip,mcs814x-intc" +- interrupt-controller: identifies the node as an interrupt controller +- #interrupt-cells: the number of cells to define the interrupts. Should be 1. +The cells are the IRQ number +- reg: contains the base address register and length, there should be only 1 + cell + +Example: + intc: interrupt-controller at 400e4000 { + compatible = "moschip,mcs814x-intc"; + interrupt-controller; + #interrupt-cells = <1>; + reg = <0x400e4000 0x48>; + };
Documentation/devicetree/bindings/arm/mcs814x/mcs814x-pci.txt new file +16 -0
@@ -0,0 +1,16 @@ +Moschip MCS814x PCI controller bindings +--------------------------------------- + +Required properties: +- compatible: should be "moschip,mcs814x-pci" +- reg: should contain the base register address and length of the PCI controller + configuration register as well as the base register address and length of the + PCI eeprom emulator +- interrupts: should contain the interrupt line of the abort interrupt +- #address-cells: should be 3 +- #size-cells: should be 2 +- ranges: should contain the properly encoded PCI ranges of the IO, non-prefetchable + and prefetchable memory regions +- #interrupt-cells: should be 1 +- interrupt-map-mask: should be 0 +- interrupt-map: should be the properly encoded PCI slot/pin to interrupt line
Documentation/devicetree/bindings/arm/mcs814x/mcs814x-timer.txt new file +16 -0
@@ -0,0 +1,16 @@ +MMoschip MCS814x timer bindings +------------------------------- + +Required properties: +- compatible: should be "moschip,mcs814x-timer" +- interrupts: should be the physical interrupt number +- reg: contains the base address register and length, there should be only 1 + cell + +Example: + timer: timer at 400f800c { + compatible = "moschip,mcs814x-timer"; + interrupts = <0>; + reg = <0x400f800c 0x8>; + }; +
Documentation/devicetree/bindings/arm/mcs814x/mcs814x.txt new file +13 -0
@@ -0,0 +1,13 @@ +MMoschip MCS814x SoC bindings + +----------------------------- + +Boards including a Moschip MCS814x SoC should include the following properties + +Required root node property: +- compatible: must contain "moschip,mcs814x" + +Boards including a Moschip MCS8140 should also include the following property. + +Required root node property: +- compatible: must contain "moschip,mcs8140"
Documentation/devicetree/bindings/vendor-prefixes.txt +1 -0
@@ -28,6 +28,7 @@ linux Linux-specific binding marvell Marvell Technology Group Ltd. maxim Maxim Integrated Products mosaixtech Mosaix Technologies, Inc. +moschp Moschip Semiconductors national National Semiconductor nintendo Nintendo nvidia NVIDIA
Signature · 1 line
1.7.10.4
PATCH 3/8 ARM: MCS814x: add Device Tree bindings documentation
Quoted 12 lines · Florian Fainelli
Documentation/devicetree/bindings/arm/mcs814x/mcs814x-pci.txt new file +6
-0@@ -0,0 +1,16 @@ +Moschip MCS814x PCI controller bindings +--------------------------------------- + +Required properties: +- compatible: should be "moschip,mcs814x-pci" +- reg: should contain the base register address and length of the PCI controller
Documentation/devicetree/bindings/arm/mcs814x/mcs814x-pci.txt line 16
Quoted 10 lines
Documentation/devicetree/bindings/arm/mcs814x/mcs814x-pci.txt new file +10
-0+ configuration register as well as the base register address and length of the + PCI eeprom emulator +- interrupts: should contain the interrupt line of the abort interrupt +- #address-cells: should be 3 +- #size-cells: should be 2 +- ranges: should contain the properly encoded PCI ranges of the IO, non-prefetchable + and prefetchable memory regions +- #interrupt-cells: should be 1 +- interrupt-map-mask: should be 0 +- interrupt-map: should be the properly encoded PCI slot/pin to interrupt line
interrupt-map-mask of 0 implies that all devices are wired to the same IRQ lines, which is rather unusual. Better leave that open so the interrupt-map can be written to work on any board.
Documentation/devicetree/bindings/vendor-prefixes.txt linux Linux-specific binding · line 34
Quoted 12 lines
Documentation/devicetree/bindings/vendor-prefixes.txt +1
-0@@ -28,6 +28,7 @@ linux Linux-specific binding marvell Marvell Technology Group Ltd. maxim Maxim Integrated Products mosaixtech Mosaix Technologies, Inc. +moschp Moschip Semiconductors national National Semiconductor nintendo Nintendo nvidia NVIDIA
This string does not match what you use everywhere else. Please fix either the documentation here or every other instance. The stock ticker symbol is MOSCHIP.BO, so using "moschip" is probably better than "moschp".
Arnd
PATCH 3/8 ARM: MCS814x: add Device Tree bindings documentation
Quoted 3 lines · On Tuesday 17 July 2012 13:24:10 Arnd Bergmann wrote:
Review
Quoted 1 line · Florian Fainelli
(quoted diff) +0
-0
b/Documentation/devicetree/bindings/arm/mcs814x/mcs814x-pci.txt
Quoted 11 lines
Documentation/devicetree/bindings/arm/mcs814x/mcs814x-pci.txt line 6
Quoted 11 lines
new file mode 100644
index 0000000..de59b04Documentation/devicetree/bindings/arm/mcs814x/mcs814x-pci.txt new file +6
-0@@ -0,0 +1,16 @@ +Moschip MCS814x PCI controller bindings +--------------------------------------- + +Required properties: +- compatible: should be "moschip,mcs814x-pci" +- reg: should contain the base register address and length of the PCI
controller
Quoted 1 line
Documentation/devicetree/bindings/arm/mcs814x/mcs814x-pci.txt line 7
Quoted 1 line
Documentation/devicetree/bindings/arm/mcs814x/mcs814x-pci.txt new file +1
-0+ configuration register as well as the base register address and length
of the
Quoted 5 lines
Documentation/devicetree/bindings/arm/mcs814x/mcs814x-pci.txt
Quoted 5 lines
Documentation/devicetree/bindings/arm/mcs814x/mcs814x-pci.txt new file +5
-0+ PCI eeprom emulator +- interrupts: should contain the interrupt line of the abort interrupt +- #address-cells: should be 3 +- #size-cells: should be 2 +- ranges: should contain the properly encoded PCI ranges of the IO, non-
prefetchable
Quoted 4 lines
Documentation/devicetree/bindings/arm/mcs814x/mcs814x-pci.txt
Quoted 4 lines
Documentation/devicetree/bindings/arm/mcs814x/mcs814x-pci.txt new file +4
-0+ and prefetchable memory regions +- #interrupt-cells: should be 1 +- interrupt-map-mask: should be 0 +- interrupt-map: should be the properly encoded PCI slot/pin to interrupt
line
Quoted 6 lines
interrupt-map-mask of 0 implies that all devices are wired to the same IRQ lines, which is rather unusual. Better leave that open so the interrupt-map can be written to work on any board.
Review
Quoted 1 line
(quoted diff) +0
-0
b/Documentation/devicetree/bindings/vendor-prefixes.txt
Quoted 8 lines
Quoted 8 lines
index 6eab917..943e4f3 100644
Documentation/devicetree/bindings/vendor-prefixes.txt +1
-0@@ -28,6 +28,7 @@ linux Linux-specific binding marvell Marvell Technology Group Ltd. maxim Maxim Integrated Products mosaixtech Mosaix Technologies, Inc. +moschp Moschip Semiconductors
Quoted 8 lines
Documentation/devicetree/bindings/vendor-prefixes.txt linux Linux-specific binding · line 34
Quoted 3 lines
Documentation/devicetree/bindings/vendor-prefixes.txt +0
-0national National Semiconductor nintendo Nintendo nvidia NVIDIAThis string does not match what you use everywhere else. Please fix either the documentation here or every other instance. The stock ticker symbol is MOSCHIP.BO, so using "moschip" is probably better than "moschp".
This was actually a typo, I meant to type "moschip" instead of "moschp", I will fix that of course.
--
Florian
PATCH 4/8 ARM: MCS814X: add DTS file for Tigal/Robotech RBT-832
In reply to Florian FainelliThis DTS files defines the following specifities:
- 32MB of RAM
- 5 GPIO controlled LEDs
- LED activity for the Ethernet port
- MTD partitions
--- arch/arm/boot/dts/rbt-832.dts | 83 ++++++++++++++++++++++++++++++ arch/arm/mach-mcs814x/Kconfig | 9 ++++ arch/arm/mach-mcs814x/Makefile.boot | 2 + arch/arm/mach-mcs814x/board-mcs8140-dt.c | 1 + 4 files changed, 95 insertions(+) create mode 100644 arch/arm/boot/dts/rbt-832.dts
arch/arm/boot/dts/rbt-832.dts new file +83 -0
@@ -0,0 +1,83 @@ +/* + * rbt-832.dts - Device Tree file for Tigal RBT-832 + * + * Copyright (C) 2012, Florian Fainelli <[email protected]> + * + * Licensed under GPLv2 + */ + +/dts-v1/; +/include/ "mcs8140.dtsi" + +/ { + model = "Tigal RBT-832"; + compatible = "tigal,rbt-832", "moschip,mcs8140", "moschip,mcs814x"; + + chosen { + bootargs = "mem=32M console=ttyS0,115200 earlyprintk"; + }; + + ahb { + vci { + eth0: ethernet at 40084000 { + nuport-mac,link-activity = <0x01>; + }; + + adc { + sdram: memory at 0,0 { + reg = <0 0 0x2000000>; + }; + + nor: flash at 7,0 { + + partition at 0 { + label = "ArmBoot"; + reg = <0 0x40000>; + }; + partition at 30000 { + label = "Enviroment"; + reg = <0x40000 0x20000>; + }; + partition at 50000 { + label = "bZimage"; + reg = <0x60000 0x1a0000>; + }; + partition at 150000 { + label = "UserFS"; + reg = <0x200000 0x600000>; + }; + }; + }; + + leds { + compatible = "gpio-leds"; + + ethernet { + label = "rbt-832:red:ethernet"; + gpios = <&gpio 0 0>; // gpio 0 active high + }; + + usb0 { + label = "rbt-832:red:usb0"; + gpios = <&gpio 4 0>; // gpio 4 active high + }; + + usb1 { + label = "rbt-832:red:usb1"; + gpios = <&gpio 3 0>; // gpio 3 active high + }; + + usb2 { + label = "rbt-832:red:usb2"; + gpios = <&gpio 2 0>; // gpio 2 active high + }; + + usb3 { + label = "rbt-832:red:usb3"; + gpios = <&gpio 1 0>; // gpio 1 active high + }; + }; + }; + }; +}; +
arch/arm/mach-mcs814x/Kconfig +9 -0
@@ -6,6 +6,15 @@ config MCS8140 menu "Moschip MCS8140 boards" +config MACH_RBT_832 + bool "Tigal RBT-832" + select MCS8140 + select NEW_LEDS + select LEDS_CLASS + select LEDS_GPIO + help + Machine support for the Tigal RBT-832 board + endmenu endif
arch/arm/mach-mcs814x/Makefile.boot +2 -0
@@ -1,3 +1,5 @@ zreladdr-y := 0x00008000 params_phys-y := 0x00000008 initrd_phys-y := 0x00400000 + +dtb-$(CONFIG_MACH_RBT_832) += rbt-832.dtb
arch/arm/mach-mcs814x/board-mcs8140-dt.c +1 -0
@@ -27,6 +27,7 @@ static void __init mcs814x_dt_device_init(void) }static const char *mcs8140_dt_board_compat[]__initdata = { +"tigal,rbt-832" ,"moschip,mcs8140" ,NULL ,/* sentinel */ };
Signature · 1 line
1.7.10.4
PATCH 4/8 ARM: MCS814X: add DTS file for Tigal/Robotech RBT-832
arch/arm/boot/dts/rbt-832.dts line 18
Quoted 6 lines · Florian Fainelli
arch/arm/boot/dts/rbt-832.dts new file +6
-0+ model = "Tigal RBT-832"; + compatible = "tigal,rbt-832", "moschip,mcs8140", "moschip,mcs814x"; + + chosen { + bootargs = "mem=32M console=ttyS0,115200 earlyprintk"; + };
I think the mem=32M doesn't belong here, it's already specified in the memory node.
Quoted 10 lines
arch/arm/mach-mcs814x/Kconfig +2
-0@@ -6,6 +6,15 @@ config MCS8140 menu "Moschip MCS8140 boards" +config MACH_RBT_832 + bool "Tigal RBT-832"
arch/arm/mach-mcs814x/Kconfig config MCS8140 · line 20
Quoted 10 lines
arch/arm/mach-mcs814x/Kconfig +7
-0+ select MCS8140 + select NEW_LEDS + select LEDS_CLASS + select LEDS_GPIO + help + Machine support for the Tigal RBT-832 board + endmenu endif
I would prefer not to have any additional symbols selected by the board. It's better to put those into the defconfig.
arch/arm/mach-mcs814x/Kconfig static void __init mcs814x_dt_device_init(void) · line 33
Quoted 8 lines
arch/arm/mach-mcs814x/Kconfig +1
-0@@ -27,6 +27,7 @@ static void __init mcs814x_dt_device_init(void) } static const char *mcs8140_dt_board_compat[] __initdata = { + "tigal,rbt-832", "moschip,mcs8140", NULL, /* sentinel */ };
I'm not sure what the normal practice is these days regarding the board compatible table. I thought that we just put the soc name in there for new platforms that are already DT-only. Your .dts file contains both, so it works either way.
Arnd
PATCH 5/8 ARM: MCS814x: add DTS file for Devolo dLAN USB Extender
In reply to Florian FainelliThis patch adds support for Devolo's dLAN USB Extender board:
- 16MB of SDRAM available
- GPIO for the USB port activity
- MTD partition map
--- arch/arm/boot/dts/dlan-usb-extender.dts | 68 ++++++++++++++++++++++++++++++ arch/arm/mach-mcs814x/Kconfig | 9 ++++ arch/arm/mach-mcs814x/Makefile.boot | 1 + arch/arm/mach-mcs814x/board-mcs8140-dt.c | 1 + 4 files changed, 79 insertions(+) create mode 100644 arch/arm/boot/dts/dlan-usb-extender.dts
arch/arm/boot/dts/dlan-usb-extender.dts new file +68 -0
@@ -0,0 +1,68 @@ +/* + * dlan-usb-extender.dts - Device Tree file for Devolo dLAN USB Extender + * + * Copyright (C) 2012, Florian Fainelli <[email protected]> + * + * Licensed under GPLv2 + */ + +/dts-v1/; +/include/ "mcs8140.dtsi" + +/ { + model = "Devolo dLAN USB Extender"; + compatible = "devolo,dlan-usb-extender", "moschip,mcs8140", "moschip,mcs814x"; + + chosen { + bootargs = "mem=16M console=ttyS0,57600 earlyprintk"; + }; + + ahb { + vci { + + adc { + sdram: memory at 0,0 { + reg = <0 0 0x1000000>; + }; + + nor: flash at 7,0 { + + partition at 0 { + label = "ArmBoot"; + reg = <0 0x30000>; + }; + partition at 30000 { + label = "Config1"; + reg = <0x30000 0x10000>; + }; + partition at 40000 { + label = "Config2"; + reg = <0x40000 0x10000>; + }; + partition at 50000 { + label = "bZimage"; + reg = <0x50000 0x100000>; + }; + partition at 150000 { + label = "UserFS"; + reg = <0x150000 0x3C0000>; + }; + partition at 50001 { + label = "Combined"; + reg = <0x50000 0x4C0000>; + }; + }; + }; + + leds { + compatible = "gpio-leds"; + + usb { + label = "dlan-usb-extender:green:usb"; + gpios = <&gpio 19 0>; // gpio 19 active high + }; + }; + }; + }; +}; +
arch/arm/mach-mcs814x/Kconfig +9 -0
@@ -6,6 +6,15 @@ config MCS8140 menu "Moschip MCS8140 boards" +config MACH_DLAN_USB_EXT + bool "Devolo dLAN USB Extender" + select MCS8140 + select NEW_LEDS + select LEDS_CLASS + select LEDS_GPIO + help + Machine support for the Devolo dLAN USB Extender + config MACH_RBT_832 bool "Tigal RBT-832" select MCS8140
arch/arm/mach-mcs814x/Makefile.boot +1 -0
@@ -2,4 +2,5 @@ params_phys-y := 0x00000008 initrd_phys-y := 0x00400000 +dtb-$(CONFIG_MACH_DLAN_USB_EXT) += dlan-usb-extender.dtb dtb-$(CONFIG_MACH_RBT_832) += rbt-832.dtb
arch/arm/mach-mcs814x/board-mcs8140-dt.c +1 -0
@@ -27,6 +27,7 @@ static void __init mcs814x_dt_device_init(void) }static const char *mcs8140_dt_board_compat[]__initdata = { +"devolo,dlan-usb-extender" ,"tigal,rbt-832" ,"moschip,mcs8140" ,NULL ,/* sentinel */
Signature · 1 line
1.7.10.4
PATCH 6/8 ARM: MCS814x: provide a sample defconfig file
In reply to Florian Fainelli--- arch/arm/configs/mcs814x_defconfig | 174 ++++++++++++++++++++++++++++++++++++ 1 file changed, 174 insertions(+) create mode 100644 arch/arm/configs/mcs814x_defconfig
arch/arm/configs/mcs814x_defconfig new file +174 -0
@@ -0,0 +1,174 @@ +# CONFIG_ARM_PATCH_PHYS_VIRT is not set +CONFIG_EXPERIMENTAL=y +# CONFIG_LOCALVERSION_AUTO is not set +# CONFIG_SWAP is not set +CONFIG_SYSVIPC=y +CONFIG_BSD_PROCESS_ACCT=y +CONFIG_LOG_BUF_SHIFT=14 +CONFIG_CC_OPTIMIZE_FOR_SIZE=y +CONFIG_SYSCTL_SYSCALL=y +# CONFIG_KALLSYMS is not set +# CONFIG_AIO is not set +CONFIG_EMBEDDED=y +# CONFIG_COMPAT_BRK is not set +CONFIG_SLAB=y +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +# CONFIG_BLK_DEV_BSG is not set +CONFIG_ARCH_MCS814X=y +CONFIG_MACH_DLAN_USB_EXT=y +CONFIG_MACH_RBT_832=y +# CONFIG_ARM_THUMB is not set +CONFIG_PCI_DEBUG=y +CONFIG_AEABI=y +CONFIG_USE_OF=y +CONFIG_ARM_APPENDED_DTB=y +CONFIG_CMDLINE="earlyprintk" +CONFIG_CMDLINE_EXTEND=y +CONFIG_FPE_NWFPE=y +# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set +CONFIG_BINFMT_MISC=y +# CONFIG_SUSPEND is not set +CONFIG_NET=y +CONFIG_PACKET=y +CONFIG_UNIX=y +CONFIG_NET_KEY=y +CONFIG_INET=y +CONFIG_IP_PNP=y +# CONFIG_INET_XFRM_MODE_TRANSPORT is not set +# CONFIG_INET_XFRM_MODE_TUNNEL is not set +# CONFIG_INET_XFRM_MODE_BEET is not set +# CONFIG_INET_LRO is not set +CONFIG_TCP_CONG_ADVANCED=y +CONFIG_TCP_CONG_BIC=y +# CONFIG_TCP_CONG_WESTWOOD is not set +CONFIG_TCP_CONG_HTCP=y +# CONFIG_IPV6 is not set +CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" +# CONFIG_PREVENT_FIRMWARE_BUILD is not set +# CONFIG_FIRMWARE_IN_KERNEL is not set +CONFIG_MTD=y +CONFIG_MTD_CHAR=y +CONFIG_MTD_BLOCK=y +CONFIG_MTD_CFI=y +CONFIG_MTD_JEDECPROBE=y +CONFIG_MTD_CFI_INTELEXT=y +CONFIG_MTD_CFI_AMDSTD=y +CONFIG_MTD_PHYSMAP=y +CONFIG_MTD_PHYSMAP_OF=y +CONFIG_PROC_DEVICETREE=y +# CONFIG_BLK_DEV is not set +CONFIG_SCSI=m +CONFIG_BLK_DEV_SD=m +CONFIG_SCSI_MULTI_LUN=y +CONFIG_NETDEVICES=y +CONFIG_MII=y +# CONFIG_NET_VENDOR_3COM is not set +# CONFIG_NET_VENDOR_ADAPTEC is not set +# CONFIG_NET_VENDOR_ALTEON is not set +# CONFIG_NET_VENDOR_AMD is not set +# CONFIG_NET_VENDOR_ATHEROS is not set +# CONFIG_NET_VENDOR_BROADCOM is not set +# CONFIG_NET_VENDOR_BROCADE is not set +# CONFIG_NET_VENDOR_CHELSIO is not set +# CONFIG_NET_VENDOR_CISCO is not set +# CONFIG_NET_VENDOR_DEC is not set +# CONFIG_NET_VENDOR_DLINK is not set +# CONFIG_NET_VENDOR_EMULEX is not set +# CONFIG_NET_VENDOR_EXAR is not set +# CONFIG_NET_VENDOR_FARADAY is not set +# CONFIG_NET_VENDOR_HP is not set +# CONFIG_NET_VENDOR_INTEL is not set +# CONFIG_NET_VENDOR_MARVELL is not set +# CONFIG_NET_VENDOR_MELLANOX is not set +# CONFIG_NET_VENDOR_MICREL is not set +# CONFIG_NET_VENDOR_MYRI is not set +# CONFIG_NET_VENDOR_NATSEMI is not set +# CONFIG_NET_VENDOR_NVIDIA is not set +# CONFIG_NET_VENDOR_OKI is not set +# CONFIG_NET_PACKET_ENGINE is not set +# CONFIG_NET_VENDOR_QLOGIC is not set +# CONFIG_NET_VENDOR_REALTEK is not set +# CONFIG_NET_VENDOR_RDC is not set +# CONFIG_NET_VENDOR_SEEQ is not set +# CONFIG_NET_VENDOR_SILAN is not set +# CONFIG_NET_VENDOR_SIS is not set +# CONFIG_NET_VENDOR_SMSC is not set +# CONFIG_NET_VENDOR_STMICRO is not set +# CONFIG_NET_VENDOR_SUN is not set +# CONFIG_NET_VENDOR_TEHUTI is not set +# CONFIG_NET_VENDOR_TI is not set +# CONFIG_NET_VENDOR_VIA is not set +CONFIG_PHYLIB=y +# CONFIG_INPUT_MOUSEDEV is not set +# CONFIG_INPUT_KEYBOARD is not set +# CONFIG_INPUT_MOUSE is not set +CONFIG_INPUT_MISC=y +# CONFIG_SERIO is not set +# CONFIG_VT is not set +# CONFIG_LEGACY_PTYS is not set +# CONFIG_DEVKMEM is not set +CONFIG_SERIAL_8250=y +CONFIG_SERIAL_8250_CONSOLE=y +# CONFIG_SERIAL_8250_PCI is not set +CONFIG_SERIAL_8250_NR_UARTS=2 +CONFIG_SERIAL_8250_RUNTIME_UARTS=2 +CONFIG_SERIAL_OF_PLATFORM=y +CONFIG_HW_RANDOM=y +CONFIG_GPIO_SYSFS=y +# CONFIG_HWMON is not set +CONFIG_WATCHDOG=y +CONFIG_WATCHDOG_CORE=y +CONFIG_WATCHDOG_NOWAYOUT=y +# CONFIG_VGA_ARB is not set +CONFIG_USB=m +CONFIG_USB_EHCI_HCD=m +CONFIG_USB_EHCI_ROOT_HUB_TT=y +# CONFIG_USB_EHCI_TT_NEWSCHED is not set +CONFIG_USB_OHCI_HCD=m +CONFIG_USB_STORAGE=m +CONFIG_LEDS_TRIGGERS=y +CONFIG_STAGING=y +# CONFIG_IOMMU_SUPPORT is not set +CONFIG_EXT4_FS=m +# CONFIG_FILE_LOCKING is not set +# CONFIG_DNOTIFY is not set +CONFIG_VFAT_FS=m +# CONFIG_PROC_PAGE_MONITOR is not set +CONFIG_TMPFS=y +CONFIG_TMPFS_XATTR=y +CONFIG_JFFS2_FS=y +CONFIG_JFFS2_FS_XATTR=y +# CONFIG_JFFS2_FS_POSIX_ACL is not set +# CONFIG_JFFS2_FS_SECURITY is not set +CONFIG_JFFS2_COMPRESSION_OPTIONS=y +CONFIG_JFFS2_LZO=y +CONFIG_JFFS2_RUBIN=y +CONFIG_SQUASHFS=y +# CONFIG_SQUASHFS_ZLIB is not set +CONFIG_SQUASHFS_XZ=y +CONFIG_NLS=y +CONFIG_NLS_DEFAULT="iso8859-15" +CONFIG_NLS_ISO8859_1=m +CONFIG_NLS_ISO8859_15=m +CONFIG_NLS_UTF8=m +CONFIG_PRINTK_TIME=y +# CONFIG_ENABLE_WARN_DEPRECATED is not set +# CONFIG_ENABLE_MUST_CHECK is not set +CONFIG_MAGIC_SYSRQ=y +CONFIG_STRIP_ASM_SYMS=y +CONFIG_DEBUG_FS=y +# CONFIG_DEBUG_BUGVERBOSE is not set +# CONFIG_FTRACE is not set +# CONFIG_ARM_UNWIND is not set +# CONFIG_CRYPTO_ANSI_CPRNG is not set +# CONFIG_CRYPTO_HW is not set +CONFIG_CRC_CCITT=y +CONFIG_CRC_ITU_T=y +CONFIG_LIBCRC32C=y +# CONFIG_XZ_DEC_X86 is not set +# CONFIG_XZ_DEC_POWERPC is not set +# CONFIG_XZ_DEC_IA64 is not set +# CONFIG_XZ_DEC_ARM is not set +# CONFIG_XZ_DEC_ARMTHUMB is not set +# CONFIG_XZ_DEC_SPARC is not set
Signature · 1 line
1.7.10.4
PATCH 7/8 ARM: MSC814X: add Kconfig and Makefile to arch/arm
In reply to Florian FainelliThis patch makes arch/arm/{Kconfig,Makefile} reference the MCS814x machine code that we can now select and build it.
--- arch/arm/Kconfig | 15 +++++++++++++++ arch/arm/Makefile | 1 + 2 files changed, 16 insertions(+)
arch/arm/Kconfig +15 -0
@@ -618,6 +618,19 @@ config ARCH_KS8695 Support for Micrel/Kendin KS8695 "Centaur" (ARM922T) based System-on-Chip devices. +config ARCH_MCS814X + bool "Moschip MCS814x" + select PCI + select FIQ + select GENERIC_IRQ_CHIP + select GENERIC_GPIO + select ARCH_REQUIRE_GPIOLIB + select CLKDEV_LOOKUP + select ARCH_USES_GETTIMEOFFSET + select NEED_MACH_MEMORY_H + help + Support for Moschip MCS814x SoCs (MCS8140 currently). + config ARCH_W90X900 bool "Nuvoton W90X900 CPU" select CPU_ARM926T
@@ -1054,6 +1067,8 @@ source "arch/arm/mach-sa1100/Kconfig" source "arch/arm/plat-samsung/Kconfig" source "arch/arm/plat-s3c24xx/Kconfig" +source "arch/arm/mach-mcs814x/Kconfig" + source "arch/arm/plat-spear/Kconfig" source "arch/arm/mach-s3c24xx/Kconfig"
arch/arm/Makefile +1 -0
@@ -151,6 +151,7 @@ machine-$(CONFIG_ARCH_IXP4XX) := ixp4xx machine-$(CONFIG_ARCH_KIRKWOOD) := kirkwood machine-$(CONFIG_ARCH_KS8695) := ks8695 machine-$(CONFIG_ARCH_LPC32XX) := lpc32xx +machine-$(CONFIG_ARCH_MCS814X) := mcs814x machine-$(CONFIG_ARCH_MMP) := mmp machine-$(CONFIG_ARCH_MSM) := msm machine-$(CONFIG_ARCH_MV78XX0) := mv78xx0
Signature · 1 line
1.7.10.4
PATCH 8/8 ARM: MSC814x: add MAINTAINERS entry
In reply to Florian Fainelli--- MAINTAINERS | 6 ++++++ 1 file changed, 6 insertions(+)
MAINTAINERS +6 -0
@@ -918,6 +918,12 @@ L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers) F: arch/arm/mach-pxa/mioa701.c S: Maintained +ARM/MOSCHIP MCS814X SUPPORT +M: Florian Fainelli <[email protected]> +L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers) +F: arch/arm/mach-mcs814x +S: Maintained + ARM/NEC MOBILEPRO 900/c MACHINE SUPPORT M: Michael Petchkovsky <[email protected]> S: Maintained
Signature · 1 line
1.7.10.4
cover ARM: support for Moschip MCS814x SoCs
In reply to Florian FainelliQuoted 6 lines · Florian Fainelli
This patchset adds basic support for Mocship MCS814x, and in particular MCS8140, and allows one booting to user space. Two off-the-shelf boards are support: Tigal/Robotech RBT-832 and Devolo dLAN USB Extender.
Support for other on-board peripherals will obviously be contributed later once the basic SoC support has been accepted.
Hi Florian,
This looks quite nice at first sight, but I have to say that your timing is rather unfortunate. We're getting rather close to the 3.6 merge window, so there is not much time to review the platform thoroughly before that and I'd feel more comfortable about putting it into 3.7. I'll let others weigh in, too. At least there is no risk of regressions for a new platform getting added, so if other people think we should take it for 3.5, I might get convinced.
I'll follow up with more detailed feedback on the individual patches.
Arnd
cover ARM: support for Moschip MCS814x SoCs
Hello Arnd,
Quoted 10 lines · On Sunday 15 July 2012 19:59:19 Arnd Bergmann wrote:
Quoted 6 lines · Florian Fainelli
This patchset adds basic support for Mocship MCS814x, and in particular MCS8140, and allows one booting to user space. Two off-the-shelf boards are support: Tigal/Robotech RBT-832 and Devolo dLAN USB Extender.
Support for other on-board peripherals will obviously be contributed later once the basic SoC support has been accepted.
Hi Florian,
Quoted 7 lines
This looks quite nice at first sight, but I have to say that your timing is rather unfortunate. We're getting rather close to the 3.6 merge window, so there is not much time to review the platform thoroughly before that and I'd feel more comfortable about putting it into 3.7. I'll let others weigh in, too. At least there is no risk of regressions for a new platform getting added, so if other people think we should take it for 3.5, I might get convinced.
I am not in a hurry getting this merged during the 3.6 merge window, so this really is not a big deal for me, I just wanted this out so that people can comment on it.
Quoted 2 lines
I'll follow up with more detailed feedback on the individual patches.
Thank you!
--
Florian
cover ARM: support for Moschip MCS814x SoCs
In reply to Arnd BergmannQuoted 10 lines · Arnd Bergmann
Quoted 6 lines · Florian Fainelli
This patchset adds basic support for Mocship MCS814x, and in particular MCS8140, and allows one booting to user space. Two off-the-shelf boards are support: Tigal/Robotech RBT-832 and Devolo dLAN USB Extender.
Support for other on-board peripherals will obviously be contributed later once the basic SoC support has been accepted.
Hi Florian,
Quoted 7 lines
This looks quite nice at first sight, but I have to say that your timing is rather unfortunate. We're getting rather close to the 3.6 merge window, so there is not much time to review the platform thoroughly before that and I'd feel more comfortable about putting it into 3.7. I'll let others weigh in, too. At least there is no risk of regressions for a new platform getting added, so if other people think we should take it for 3.5, I might get convinced.
You should take it if no apparent issues are found. As you say, this might even be broken and no one else would be affected. The only reasons I would not push it upstream are about the code i.e if the code causes merge conflicts, isn't up to date with the latest kernel infrastructures or has coding style issues, etc.
Nicolas