* [PATCH v4 0/2] ARM: mach-moxart: add MOXA ART SoC support @ 2013-12-13 14:33 ` Jonas Jensen 0 siblings, 0 replies; 44+ messages in thread From: Jonas Jensen @ 2013-12-13 14:33 UTC (permalink / raw) To: linux-arm-kernel Cc: linux-kernel, devicetree-discuss, arm, linux, arnd, olof, Jonas Jensen This set adds MOXA ART SoC and platform support. Changes since v3: 1. removed platform specific UART debug files, replaced by generic code under DEBUG_LL_UART_8250. arch/arm/mach-moxart/*: 2. select DMA_OF and PHYLIB 3. remove .init_time hook 4. reinsert restart code that rely on watchdog register (watchdog maintainers rejected arm_pm_restart in watchdog code) assign arm_pm_restart from .init_machine 5. move to ARCH_MULTI_V4T (ARCH_MULTI_V4 was removed) arch/arm/boot/dts/moxart-uc7112lx.dts: 6. remove comments 7. add "mdio0"/"mdio1" nodes 8. add phy-handle/phy-mode to "mac0"/"mac1" nodes 9. change bootargs (change root=/dev/mtdblock2 to root=/dev/mmcblk0p1) 10. add gpio-leds node "leds" 11. add gpio-keys-polled node "gpio_keys_polled" 12. rename "mmc" node "sdhci" arch/arm/boot/dts/moxart.dtsi: 13. add fixed-clock node "ref12" 14. remove "clk" node, add nodes "clk_pll"/"clk_apb" 15. add gpio-rtc-* (sclk|data|reset) to "rtc" node 16. add "dma" node 17. remove second register from "gpio" node Applies to next-20131213 Jonas Jensen (2): ARM: mach-moxart: add MOXA ART SoC platform files ARM: mach-moxart: add MOXA ART SoC device tree files Documentation/devicetree/bindings/arm/moxart.txt | 12 ++ arch/arm/Kconfig | 2 + arch/arm/Makefile | 1 + arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/moxart-uc7112lx.dts | 131 ++++++++++++++++++++ arch/arm/boot/dts/moxart.dtsi | 100 +++++++++++++++ arch/arm/configs/moxart_defconfig | 148 +++++++++++++++++++++++ arch/arm/mach-moxart/Kconfig | 31 +++++ arch/arm/mach-moxart/Makefile | 3 + arch/arm/mach-moxart/moxart.c | 75 ++++++++++++ 10 files changed, 504 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/moxart.txt create mode 100644 arch/arm/boot/dts/moxart-uc7112lx.dts create mode 100644 arch/arm/boot/dts/moxart.dtsi create mode 100644 arch/arm/configs/moxart_defconfig create mode 100644 arch/arm/mach-moxart/Kconfig create mode 100644 arch/arm/mach-moxart/Makefile create mode 100644 arch/arm/mach-moxart/moxart.c -- 1.8.2.1 ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v4 0/2] ARM: mach-moxart: add MOXA ART SoC support @ 2013-12-13 14:33 ` Jonas Jensen 0 siblings, 0 replies; 44+ messages in thread From: Jonas Jensen @ 2013-12-13 14:33 UTC (permalink / raw) To: linux-arm-kernel This set adds MOXA ART SoC and platform support. Changes since v3: 1. removed platform specific UART debug files, replaced by generic code under DEBUG_LL_UART_8250. arch/arm/mach-moxart/*: 2. select DMA_OF and PHYLIB 3. remove .init_time hook 4. reinsert restart code that rely on watchdog register (watchdog maintainers rejected arm_pm_restart in watchdog code) assign arm_pm_restart from .init_machine 5. move to ARCH_MULTI_V4T (ARCH_MULTI_V4 was removed) arch/arm/boot/dts/moxart-uc7112lx.dts: 6. remove comments 7. add "mdio0"/"mdio1" nodes 8. add phy-handle/phy-mode to "mac0"/"mac1" nodes 9. change bootargs (change root=/dev/mtdblock2 to root=/dev/mmcblk0p1) 10. add gpio-leds node "leds" 11. add gpio-keys-polled node "gpio_keys_polled" 12. rename "mmc" node "sdhci" arch/arm/boot/dts/moxart.dtsi: 13. add fixed-clock node "ref12" 14. remove "clk" node, add nodes "clk_pll"/"clk_apb" 15. add gpio-rtc-* (sclk|data|reset) to "rtc" node 16. add "dma" node 17. remove second register from "gpio" node Applies to next-20131213 Jonas Jensen (2): ARM: mach-moxart: add MOXA ART SoC platform files ARM: mach-moxart: add MOXA ART SoC device tree files Documentation/devicetree/bindings/arm/moxart.txt | 12 ++ arch/arm/Kconfig | 2 + arch/arm/Makefile | 1 + arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/moxart-uc7112lx.dts | 131 ++++++++++++++++++++ arch/arm/boot/dts/moxart.dtsi | 100 +++++++++++++++ arch/arm/configs/moxart_defconfig | 148 +++++++++++++++++++++++ arch/arm/mach-moxart/Kconfig | 31 +++++ arch/arm/mach-moxart/Makefile | 3 + arch/arm/mach-moxart/moxart.c | 75 ++++++++++++ 10 files changed, 504 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/moxart.txt create mode 100644 arch/arm/boot/dts/moxart-uc7112lx.dts create mode 100644 arch/arm/boot/dts/moxart.dtsi create mode 100644 arch/arm/configs/moxart_defconfig create mode 100644 arch/arm/mach-moxart/Kconfig create mode 100644 arch/arm/mach-moxart/Makefile create mode 100644 arch/arm/mach-moxart/moxart.c -- 1.8.2.1 ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files 2013-12-13 14:33 ` Jonas Jensen @ 2013-12-13 14:33 ` Jonas Jensen -1 siblings, 0 replies; 44+ messages in thread From: Jonas Jensen @ 2013-12-13 14:33 UTC (permalink / raw) To: linux-arm-kernel Cc: linux-kernel, devicetree-discuss, arm, linux, arnd, olof, Jonas Jensen The MOXA ART SoC is based on Faraday's FA526. This is a ARMv4 32-bit 192 MHz CPU with MMU and 16KB/8KB D/I-cache. Add platform support for this SoC. Also add UC-7112-LX as a machine. Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com> --- arch/arm/Kconfig | 2 + arch/arm/Makefile | 1 + arch/arm/configs/moxart_defconfig | 148 ++++++++++++++++++++++++++++++++++++++ arch/arm/mach-moxart/Kconfig | 31 ++++++++ arch/arm/mach-moxart/Makefile | 3 + arch/arm/mach-moxart/moxart.c | 75 +++++++++++++++++++ 6 files changed, 260 insertions(+) create mode 100644 arch/arm/configs/moxart_defconfig create mode 100644 arch/arm/mach-moxart/Kconfig create mode 100644 arch/arm/mach-moxart/Makefile create mode 100644 arch/arm/mach-moxart/moxart.c diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index b64a8ef..04cd39f 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -949,6 +949,8 @@ source "arch/arm/mach-ks8695/Kconfig" source "arch/arm/mach-msm/Kconfig" +source "arch/arm/mach-moxart/Kconfig" + source "arch/arm/mach-mv78xx0/Kconfig" source "arch/arm/mach-imx/Kconfig" diff --git a/arch/arm/Makefile b/arch/arm/Makefile index 1edf8eb..4965742 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -167,6 +167,7 @@ machine-$(CONFIG_ARCH_KIRKWOOD) += kirkwood machine-$(CONFIG_ARCH_KS8695) += ks8695 machine-$(CONFIG_ARCH_LPC32XX) += lpc32xx machine-$(CONFIG_ARCH_MMP) += mmp +machine-$(CONFIG_ARCH_MOXART) += moxart machine-$(CONFIG_ARCH_MSM) += msm machine-$(CONFIG_ARCH_MV78XX0) += mv78xx0 machine-$(CONFIG_ARCH_MVEBU) += mvebu diff --git a/arch/arm/configs/moxart_defconfig b/arch/arm/configs/moxart_defconfig new file mode 100644 index 0000000..51f0f03 --- /dev/null +++ b/arch/arm/configs/moxart_defconfig @@ -0,0 +1,148 @@ +# CONFIG_LOCALVERSION_AUTO is not set +# CONFIG_SWAP is not set +CONFIG_SYSVIPC=y +CONFIG_NO_HZ=y +CONFIG_IKCONFIG=y +CONFIG_IKCONFIG_PROC=y +CONFIG_SYSCTL_SYSCALL=y +# CONFIG_ELF_CORE is not set +# CONFIG_BASE_FULL is not set +# CONFIG_SIGNALFD is not set +# CONFIG_TIMERFD is not set +# CONFIG_EVENTFD is not set +# CONFIG_AIO is not set +CONFIG_EMBEDDED=y +# CONFIG_VM_EVENT_COUNTERS is not set +# CONFIG_SLUB_DEBUG is not set +# CONFIG_COMPAT_BRK is not set +# CONFIG_LBDAF is not set +# CONFIG_BLK_DEV_BSG is not set +# CONFIG_IOSCHED_DEADLINE is not set +CONFIG_ARCH_MULTI_V4T=y +# CONFIG_ARCH_MULTI_V7 is not set +CONFIG_KEYBOARD_GPIO_POLLED=y +CONFIG_ARCH_MOXART=y +CONFIG_MACH_UC7112LX=y +# CONFIG_ARM_THUMB is not set +CONFIG_PREEMPT=y +CONFIG_AEABI=y +# CONFIG_ATAGS is not set +CONFIG_ARM_APPENDED_DTB=y +CONFIG_NET=y +CONFIG_UNIX=y +CONFIG_INET=y +CONFIG_IP_PNP=y +CONFIG_IP_PNP_DHCP=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_INET_DIAG is not set +# CONFIG_IPV6 is not set +# CONFIG_WIRELESS is not set +CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" +CONFIG_DEVTMPFS=y +CONFIG_DEVTMPFS_MOUNT=y +# CONFIG_PREVENT_FIRMWARE_BUILD is not set +# CONFIG_FW_LOADER is not set +CONFIG_MTD=y +CONFIG_MTD_BLOCK=y +CONFIG_MTD_CFI=y +CONFIG_MTD_CFI_ADV_OPTIONS=y +CONFIG_MTD_CFI_GEOMETRY=y +CONFIG_MTD_CFI_INTELEXT=y +CONFIG_MTD_COMPLEX_MAPPINGS=y +CONFIG_MTD_PHYSMAP=y +CONFIG_MTD_PHYSMAP_OF=y +CONFIG_PROC_DEVICETREE=y +CONFIG_NETDEVICES=y +CONFIG_NETCONSOLE=y +CONFIG_NETCONSOLE_DYNAMIC=y +# CONFIG_NET_VENDOR_ARC is not set +# CONFIG_NET_CADENCE is not set +# CONFIG_NET_VENDOR_BROADCOM is not set +# CONFIG_NET_VENDOR_CIRRUS is not set +# CONFIG_NET_VENDOR_FARADAY is not set +# CONFIG_NET_VENDOR_INTEL is not set +# CONFIG_NET_VENDOR_MARVELL is not set +# CONFIG_NET_VENDOR_MICREL is not set +CONFIG_ARM_MOXART_ETHER=y +# CONFIG_NET_VENDOR_NATSEMI is not set +# CONFIG_NET_VENDOR_SEEQ is not set +# CONFIG_NET_VENDOR_SMSC is not set +# CONFIG_NET_VENDOR_STMICRO is not set +# CONFIG_NET_VENDOR_VIA is not set +# CONFIG_NET_VENDOR_WIZNET is not set +CONFIG_REALTEK_PHY=y +CONFIG_MDIO_MOXART=y +# CONFIG_WLAN is not set +# CONFIG_INPUT_MOUSEDEV is not set +CONFIG_INPUT_EVDEV=y +CONFIG_INPUT_EVBUG=y +# CONFIG_KEYBOARD_ATKBD is not set +# CONFIG_INPUT_MOUSE is not set +# 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_NR_UARTS=1 +CONFIG_SERIAL_8250_RUNTIME_UARTS=1 +CONFIG_SERIAL_8250_EXTENDED=y +CONFIG_SERIAL_8250_SHARE_IRQ=y +CONFIG_SERIAL_OF_PLATFORM=y +# CONFIG_HW_RANDOM is not set +CONFIG_DEBUG_GPIO=y +CONFIG_GPIO_SYSFS=y +CONFIG_GPIO_MOXART=y +CONFIG_POWER_SUPPLY=y +CONFIG_POWER_RESET=y +CONFIG_POWER_RESET_GPIO=y +# CONFIG_HWMON is not set +CONFIG_WATCHDOG=y +CONFIG_WATCHDOG_CORE=y +CONFIG_WATCHDOG_NOWAYOUT=y +CONFIG_MOXART_WDT=y +# CONFIG_USB_SUPPORT is not set +CONFIG_MMC=y +CONFIG_MMC_SDHCI_MOXART=y +CONFIG_NEW_LEDS=y +CONFIG_LEDS_CLASS=y +CONFIG_LEDS_GPIO=y +CONFIG_LEDS_TRIGGER_TIMER=y +CONFIG_LEDS_TRIGGER_ONESHOT=y +CONFIG_LEDS_TRIGGER_HEARTBEAT=y +CONFIG_LEDS_TRIGGER_DEFAULT_ON=y +CONFIG_RTC_CLASS=y +CONFIG_RTC_DRV_MOXART=y +CONFIG_DMADEVICES=y +CONFIG_MOXART_DMA=y +# CONFIG_IOMMU_SUPPORT is not set +CONFIG_EXT3_FS=y +CONFIG_TMPFS=y +CONFIG_CONFIGFS_FS=y +CONFIG_JFFS2_FS=y +CONFIG_PRINTK_TIME=y +CONFIG_DEBUG_INFO=y +# CONFIG_ENABLE_WARN_DEPRECATED is not set +# CONFIG_ENABLE_MUST_CHECK is not set +CONFIG_DEBUG_PAGEALLOC=y +CONFIG_DEBUG_OBJECTS=y +CONFIG_DEBUG_KMEMLEAK=y +CONFIG_DEBUG_STACK_USAGE=y +CONFIG_DEBUG_MEMORY_INIT=y +CONFIG_DEBUG_SHIRQ=y +CONFIG_DETECT_HUNG_TASK=y +# CONFIG_SCHED_DEBUG is not set +# CONFIG_DEBUG_PREEMPT is not set +CONFIG_PROVE_LOCKING=y +CONFIG_DMA_API_DEBUG=y +CONFIG_KGDB=y +CONFIG_DEBUG_LL=y +CONFIG_DEBUG_LL_UART_8250=y +CONFIG_DEBUG_UART_PHYS=0x98200000 +CONFIG_DEBUG_UART_VIRT=0xf9820000 +CONFIG_EARLY_PRINTK=y +CONFIG_KEYS=y +CONFIG_CRC32_BIT=y diff --git a/arch/arm/mach-moxart/Kconfig b/arch/arm/mach-moxart/Kconfig new file mode 100644 index 0000000..ba470d6 --- /dev/null +++ b/arch/arm/mach-moxart/Kconfig @@ -0,0 +1,31 @@ +config ARCH_MOXART + bool "MOXA ART SoC" if ARCH_MULTI_V4T + select CPU_FA526 + select ARM_DMA_MEM_BUFFERABLE + select DMA_OF + select USE_OF + select CLKSRC_OF + select CLKSRC_MMIO + select HAVE_CLK + select COMMON_CLK + select GENERIC_IRQ_CHIP + select ARCH_REQUIRE_GPIOLIB + select GENERIC_CLOCKEVENTS + select PHYLIB if NETDEVICES + help + Say Y here if you want to run your kernel on hardware with a + MOXA ART SoC. + The MOXA ART SoC is based on a Faraday FA526 ARMv4 32-bit + 192 MHz CPU with MMU and 16KB/8KB D/I-cache (UC-7112-LX). + Used on models UC-7101, UC-7112/UC-7110, IA240/IA241, IA3341. + +if ARCH_MOXART + +config MACH_UC7112LX + bool "MOXA UC-7112-LX" + depends on ARCH_MOXART + help + Say Y here if you intend to run this kernel on a MOXA + UC-7112-LX embedded computer. + +endif diff --git a/arch/arm/mach-moxart/Makefile b/arch/arm/mach-moxart/Makefile new file mode 100644 index 0000000..fa022eb --- /dev/null +++ b/arch/arm/mach-moxart/Makefile @@ -0,0 +1,3 @@ +# Object file lists. + +obj-$(CONFIG_MACH_UC7112LX) += moxart.o diff --git a/arch/arm/mach-moxart/moxart.c b/arch/arm/mach-moxart/moxart.c new file mode 100644 index 0000000..491458a --- /dev/null +++ b/arch/arm/mach-moxart/moxart.c @@ -0,0 +1,75 @@ +/* + * arch/arm/mach-moxart/moxart.c + * + * (C) Copyright 2013, Jonas Jensen <jonas.jensen@gmail.com> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include <linux/init.h> +#include <linux/of_platform.h> +#include <linux/of_address.h> +#include <linux/io.h> + +#include <asm/mach/arch.h> +#include <asm/system_misc.h> + +#define REG_COUNT 0x4 +#define REG_MODE 0x8 +#define REG_ENABLE 0xC + +static void __iomem *moxart_wdt_base; + +static void moxart_wdt_restart(enum reboot_mode reboot_mode, const char *cmd) +{ + writel(1, moxart_wdt_base + REG_COUNT); + writel(0x5ab9, moxart_wdt_base + REG_MODE); + writel(0x03, moxart_wdt_base + REG_ENABLE); +} + +static const struct of_device_id moxart_watchdog_match[] = { + { .compatible = "moxa,moxart-watchdog", .data = moxart_wdt_restart }, + { }, +}; + +static void moxart_setup_restart(void) +{ + const struct of_device_id *of_id; + struct device_node *np; + + np = of_find_matching_node(NULL, moxart_watchdog_match); + if (WARN(!np, "unable to setup watchdog restart")) + return; + + moxart_wdt_base = of_iomap(np, 0); + WARN(!moxart_wdt_base, "failed to map watchdog base address"); + + of_id = of_match_node(moxart_watchdog_match, np); + WARN(!of_id, "restart function not available"); + + arm_pm_restart = of_id->data; +} + +static void __init moxart_dt_init(void) +{ + moxart_setup_restart(); + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); +} + +static const char * const moxart_dt_compat[] = { + "moxa,moxart", + NULL, +}; + +DT_MACHINE_START(MOXART, "MOXA UC-7112-LX") + .init_machine = moxart_dt_init, + .dt_compat = moxart_dt_compat, +MACHINE_END -- 1.8.2.1 ^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files @ 2013-12-13 14:33 ` Jonas Jensen 0 siblings, 0 replies; 44+ messages in thread From: Jonas Jensen @ 2013-12-13 14:33 UTC (permalink / raw) To: linux-arm-kernel The MOXA ART SoC is based on Faraday's FA526. This is a ARMv4 32-bit 192 MHz CPU with MMU and 16KB/8KB D/I-cache. Add platform support for this SoC. Also add UC-7112-LX as a machine. Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com> --- arch/arm/Kconfig | 2 + arch/arm/Makefile | 1 + arch/arm/configs/moxart_defconfig | 148 ++++++++++++++++++++++++++++++++++++++ arch/arm/mach-moxart/Kconfig | 31 ++++++++ arch/arm/mach-moxart/Makefile | 3 + arch/arm/mach-moxart/moxart.c | 75 +++++++++++++++++++ 6 files changed, 260 insertions(+) create mode 100644 arch/arm/configs/moxart_defconfig create mode 100644 arch/arm/mach-moxart/Kconfig create mode 100644 arch/arm/mach-moxart/Makefile create mode 100644 arch/arm/mach-moxart/moxart.c diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index b64a8ef..04cd39f 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -949,6 +949,8 @@ source "arch/arm/mach-ks8695/Kconfig" source "arch/arm/mach-msm/Kconfig" +source "arch/arm/mach-moxart/Kconfig" + source "arch/arm/mach-mv78xx0/Kconfig" source "arch/arm/mach-imx/Kconfig" diff --git a/arch/arm/Makefile b/arch/arm/Makefile index 1edf8eb..4965742 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -167,6 +167,7 @@ machine-$(CONFIG_ARCH_KIRKWOOD) += kirkwood machine-$(CONFIG_ARCH_KS8695) += ks8695 machine-$(CONFIG_ARCH_LPC32XX) += lpc32xx machine-$(CONFIG_ARCH_MMP) += mmp +machine-$(CONFIG_ARCH_MOXART) += moxart machine-$(CONFIG_ARCH_MSM) += msm machine-$(CONFIG_ARCH_MV78XX0) += mv78xx0 machine-$(CONFIG_ARCH_MVEBU) += mvebu diff --git a/arch/arm/configs/moxart_defconfig b/arch/arm/configs/moxart_defconfig new file mode 100644 index 0000000..51f0f03 --- /dev/null +++ b/arch/arm/configs/moxart_defconfig @@ -0,0 +1,148 @@ +# CONFIG_LOCALVERSION_AUTO is not set +# CONFIG_SWAP is not set +CONFIG_SYSVIPC=y +CONFIG_NO_HZ=y +CONFIG_IKCONFIG=y +CONFIG_IKCONFIG_PROC=y +CONFIG_SYSCTL_SYSCALL=y +# CONFIG_ELF_CORE is not set +# CONFIG_BASE_FULL is not set +# CONFIG_SIGNALFD is not set +# CONFIG_TIMERFD is not set +# CONFIG_EVENTFD is not set +# CONFIG_AIO is not set +CONFIG_EMBEDDED=y +# CONFIG_VM_EVENT_COUNTERS is not set +# CONFIG_SLUB_DEBUG is not set +# CONFIG_COMPAT_BRK is not set +# CONFIG_LBDAF is not set +# CONFIG_BLK_DEV_BSG is not set +# CONFIG_IOSCHED_DEADLINE is not set +CONFIG_ARCH_MULTI_V4T=y +# CONFIG_ARCH_MULTI_V7 is not set +CONFIG_KEYBOARD_GPIO_POLLED=y +CONFIG_ARCH_MOXART=y +CONFIG_MACH_UC7112LX=y +# CONFIG_ARM_THUMB is not set +CONFIG_PREEMPT=y +CONFIG_AEABI=y +# CONFIG_ATAGS is not set +CONFIG_ARM_APPENDED_DTB=y +CONFIG_NET=y +CONFIG_UNIX=y +CONFIG_INET=y +CONFIG_IP_PNP=y +CONFIG_IP_PNP_DHCP=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_INET_DIAG is not set +# CONFIG_IPV6 is not set +# CONFIG_WIRELESS is not set +CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" +CONFIG_DEVTMPFS=y +CONFIG_DEVTMPFS_MOUNT=y +# CONFIG_PREVENT_FIRMWARE_BUILD is not set +# CONFIG_FW_LOADER is not set +CONFIG_MTD=y +CONFIG_MTD_BLOCK=y +CONFIG_MTD_CFI=y +CONFIG_MTD_CFI_ADV_OPTIONS=y +CONFIG_MTD_CFI_GEOMETRY=y +CONFIG_MTD_CFI_INTELEXT=y +CONFIG_MTD_COMPLEX_MAPPINGS=y +CONFIG_MTD_PHYSMAP=y +CONFIG_MTD_PHYSMAP_OF=y +CONFIG_PROC_DEVICETREE=y +CONFIG_NETDEVICES=y +CONFIG_NETCONSOLE=y +CONFIG_NETCONSOLE_DYNAMIC=y +# CONFIG_NET_VENDOR_ARC is not set +# CONFIG_NET_CADENCE is not set +# CONFIG_NET_VENDOR_BROADCOM is not set +# CONFIG_NET_VENDOR_CIRRUS is not set +# CONFIG_NET_VENDOR_FARADAY is not set +# CONFIG_NET_VENDOR_INTEL is not set +# CONFIG_NET_VENDOR_MARVELL is not set +# CONFIG_NET_VENDOR_MICREL is not set +CONFIG_ARM_MOXART_ETHER=y +# CONFIG_NET_VENDOR_NATSEMI is not set +# CONFIG_NET_VENDOR_SEEQ is not set +# CONFIG_NET_VENDOR_SMSC is not set +# CONFIG_NET_VENDOR_STMICRO is not set +# CONFIG_NET_VENDOR_VIA is not set +# CONFIG_NET_VENDOR_WIZNET is not set +CONFIG_REALTEK_PHY=y +CONFIG_MDIO_MOXART=y +# CONFIG_WLAN is not set +# CONFIG_INPUT_MOUSEDEV is not set +CONFIG_INPUT_EVDEV=y +CONFIG_INPUT_EVBUG=y +# CONFIG_KEYBOARD_ATKBD is not set +# CONFIG_INPUT_MOUSE is not set +# 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_NR_UARTS=1 +CONFIG_SERIAL_8250_RUNTIME_UARTS=1 +CONFIG_SERIAL_8250_EXTENDED=y +CONFIG_SERIAL_8250_SHARE_IRQ=y +CONFIG_SERIAL_OF_PLATFORM=y +# CONFIG_HW_RANDOM is not set +CONFIG_DEBUG_GPIO=y +CONFIG_GPIO_SYSFS=y +CONFIG_GPIO_MOXART=y +CONFIG_POWER_SUPPLY=y +CONFIG_POWER_RESET=y +CONFIG_POWER_RESET_GPIO=y +# CONFIG_HWMON is not set +CONFIG_WATCHDOG=y +CONFIG_WATCHDOG_CORE=y +CONFIG_WATCHDOG_NOWAYOUT=y +CONFIG_MOXART_WDT=y +# CONFIG_USB_SUPPORT is not set +CONFIG_MMC=y +CONFIG_MMC_SDHCI_MOXART=y +CONFIG_NEW_LEDS=y +CONFIG_LEDS_CLASS=y +CONFIG_LEDS_GPIO=y +CONFIG_LEDS_TRIGGER_TIMER=y +CONFIG_LEDS_TRIGGER_ONESHOT=y +CONFIG_LEDS_TRIGGER_HEARTBEAT=y +CONFIG_LEDS_TRIGGER_DEFAULT_ON=y +CONFIG_RTC_CLASS=y +CONFIG_RTC_DRV_MOXART=y +CONFIG_DMADEVICES=y +CONFIG_MOXART_DMA=y +# CONFIG_IOMMU_SUPPORT is not set +CONFIG_EXT3_FS=y +CONFIG_TMPFS=y +CONFIG_CONFIGFS_FS=y +CONFIG_JFFS2_FS=y +CONFIG_PRINTK_TIME=y +CONFIG_DEBUG_INFO=y +# CONFIG_ENABLE_WARN_DEPRECATED is not set +# CONFIG_ENABLE_MUST_CHECK is not set +CONFIG_DEBUG_PAGEALLOC=y +CONFIG_DEBUG_OBJECTS=y +CONFIG_DEBUG_KMEMLEAK=y +CONFIG_DEBUG_STACK_USAGE=y +CONFIG_DEBUG_MEMORY_INIT=y +CONFIG_DEBUG_SHIRQ=y +CONFIG_DETECT_HUNG_TASK=y +# CONFIG_SCHED_DEBUG is not set +# CONFIG_DEBUG_PREEMPT is not set +CONFIG_PROVE_LOCKING=y +CONFIG_DMA_API_DEBUG=y +CONFIG_KGDB=y +CONFIG_DEBUG_LL=y +CONFIG_DEBUG_LL_UART_8250=y +CONFIG_DEBUG_UART_PHYS=0x98200000 +CONFIG_DEBUG_UART_VIRT=0xf9820000 +CONFIG_EARLY_PRINTK=y +CONFIG_KEYS=y +CONFIG_CRC32_BIT=y diff --git a/arch/arm/mach-moxart/Kconfig b/arch/arm/mach-moxart/Kconfig new file mode 100644 index 0000000..ba470d6 --- /dev/null +++ b/arch/arm/mach-moxart/Kconfig @@ -0,0 +1,31 @@ +config ARCH_MOXART + bool "MOXA ART SoC" if ARCH_MULTI_V4T + select CPU_FA526 + select ARM_DMA_MEM_BUFFERABLE + select DMA_OF + select USE_OF + select CLKSRC_OF + select CLKSRC_MMIO + select HAVE_CLK + select COMMON_CLK + select GENERIC_IRQ_CHIP + select ARCH_REQUIRE_GPIOLIB + select GENERIC_CLOCKEVENTS + select PHYLIB if NETDEVICES + help + Say Y here if you want to run your kernel on hardware with a + MOXA ART SoC. + The MOXA ART SoC is based on a Faraday FA526 ARMv4 32-bit + 192 MHz CPU with MMU and 16KB/8KB D/I-cache (UC-7112-LX). + Used on models UC-7101, UC-7112/UC-7110, IA240/IA241, IA3341. + +if ARCH_MOXART + +config MACH_UC7112LX + bool "MOXA UC-7112-LX" + depends on ARCH_MOXART + help + Say Y here if you intend to run this kernel on a MOXA + UC-7112-LX embedded computer. + +endif diff --git a/arch/arm/mach-moxart/Makefile b/arch/arm/mach-moxart/Makefile new file mode 100644 index 0000000..fa022eb --- /dev/null +++ b/arch/arm/mach-moxart/Makefile @@ -0,0 +1,3 @@ +# Object file lists. + +obj-$(CONFIG_MACH_UC7112LX) += moxart.o diff --git a/arch/arm/mach-moxart/moxart.c b/arch/arm/mach-moxart/moxart.c new file mode 100644 index 0000000..491458a --- /dev/null +++ b/arch/arm/mach-moxart/moxart.c @@ -0,0 +1,75 @@ +/* + * arch/arm/mach-moxart/moxart.c + * + * (C) Copyright 2013, Jonas Jensen <jonas.jensen@gmail.com> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include <linux/init.h> +#include <linux/of_platform.h> +#include <linux/of_address.h> +#include <linux/io.h> + +#include <asm/mach/arch.h> +#include <asm/system_misc.h> + +#define REG_COUNT 0x4 +#define REG_MODE 0x8 +#define REG_ENABLE 0xC + +static void __iomem *moxart_wdt_base; + +static void moxart_wdt_restart(enum reboot_mode reboot_mode, const char *cmd) +{ + writel(1, moxart_wdt_base + REG_COUNT); + writel(0x5ab9, moxart_wdt_base + REG_MODE); + writel(0x03, moxart_wdt_base + REG_ENABLE); +} + +static const struct of_device_id moxart_watchdog_match[] = { + { .compatible = "moxa,moxart-watchdog", .data = moxart_wdt_restart }, + { }, +}; + +static void moxart_setup_restart(void) +{ + const struct of_device_id *of_id; + struct device_node *np; + + np = of_find_matching_node(NULL, moxart_watchdog_match); + if (WARN(!np, "unable to setup watchdog restart")) + return; + + moxart_wdt_base = of_iomap(np, 0); + WARN(!moxart_wdt_base, "failed to map watchdog base address"); + + of_id = of_match_node(moxart_watchdog_match, np); + WARN(!of_id, "restart function not available"); + + arm_pm_restart = of_id->data; +} + +static void __init moxart_dt_init(void) +{ + moxart_setup_restart(); + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); +} + +static const char * const moxart_dt_compat[] = { + "moxa,moxart", + NULL, +}; + +DT_MACHINE_START(MOXART, "MOXA UC-7112-LX") + .init_machine = moxart_dt_init, + .dt_compat = moxart_dt_compat, +MACHINE_END -- 1.8.2.1 ^ permalink raw reply related [flat|nested] 44+ messages in thread
[parent not found: <1386945188-8316-2-git-send-email-jonas.jensen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]
* Fwd: [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files [not found] ` <1386945188-8316-2-git-send-email-jonas.jensen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> @ 2013-12-13 14:38 ` Jonas Jensen 0 siblings, 0 replies; 44+ messages in thread From: Jonas Jensen @ 2013-12-13 14:38 UTC (permalink / raw) To: devicetree-u79uwXL29TY76Z2rM5mHXA Forwarding this because I used the wrong Cc address to devicetree-u79uwXL29TaiAVqoAR/hOA@public.gmane.org ---------- Forwarded message ---------- From: Jonas Jensen <jonas.jensen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Date: 13 December 2013 15:33 Subject: [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org, arm-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org, arnd-r2nGTMty4D4@public.gmane.org, olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org, Jonas Jensen <jonas.jensen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> The MOXA ART SoC is based on Faraday's FA526. This is a ARMv4 32-bit 192 MHz CPU with MMU and 16KB/8KB D/I-cache. Add platform support for this SoC. Also add UC-7112-LX as a machine. Signed-off-by: Jonas Jensen <jonas.jensen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> --- arch/arm/Kconfig | 2 + arch/arm/Makefile | 1 + arch/arm/configs/moxart_defconfig | 148 ++++++++++++++++++++++++++++++++++++++ arch/arm/mach-moxart/Kconfig | 31 ++++++++ arch/arm/mach-moxart/Makefile | 3 + arch/arm/mach-moxart/moxart.c | 75 +++++++++++++++++++ 6 files changed, 260 insertions(+) create mode 100644 arch/arm/configs/moxart_defconfig create mode 100644 arch/arm/mach-moxart/Kconfig create mode 100644 arch/arm/mach-moxart/Makefile create mode 100644 arch/arm/mach-moxart/moxart.c diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index b64a8ef..04cd39f 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -949,6 +949,8 @@ source "arch/arm/mach-ks8695/Kconfig" source "arch/arm/mach-msm/Kconfig" +source "arch/arm/mach-moxart/Kconfig" + source "arch/arm/mach-mv78xx0/Kconfig" source "arch/arm/mach-imx/Kconfig" diff --git a/arch/arm/Makefile b/arch/arm/Makefile index 1edf8eb..4965742 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -167,6 +167,7 @@ machine-$(CONFIG_ARCH_KIRKWOOD) += kirkwood machine-$(CONFIG_ARCH_KS8695) += ks8695 machine-$(CONFIG_ARCH_LPC32XX) += lpc32xx machine-$(CONFIG_ARCH_MMP) += mmp +machine-$(CONFIG_ARCH_MOXART) += moxart machine-$(CONFIG_ARCH_MSM) += msm machine-$(CONFIG_ARCH_MV78XX0) += mv78xx0 machine-$(CONFIG_ARCH_MVEBU) += mvebu diff --git a/arch/arm/configs/moxart_defconfig b/arch/arm/configs/moxart_defconfig new file mode 100644 index 0000000..51f0f03 --- /dev/null +++ b/arch/arm/configs/moxart_defconfig @@ -0,0 +1,148 @@ +# CONFIG_LOCALVERSION_AUTO is not set +# CONFIG_SWAP is not set +CONFIG_SYSVIPC=y +CONFIG_NO_HZ=y +CONFIG_IKCONFIG=y +CONFIG_IKCONFIG_PROC=y +CONFIG_SYSCTL_SYSCALL=y +# CONFIG_ELF_CORE is not set +# CONFIG_BASE_FULL is not set +# CONFIG_SIGNALFD is not set +# CONFIG_TIMERFD is not set +# CONFIG_EVENTFD is not set +# CONFIG_AIO is not set +CONFIG_EMBEDDED=y +# CONFIG_VM_EVENT_COUNTERS is not set +# CONFIG_SLUB_DEBUG is not set +# CONFIG_COMPAT_BRK is not set +# CONFIG_LBDAF is not set +# CONFIG_BLK_DEV_BSG is not set +# CONFIG_IOSCHED_DEADLINE is not set +CONFIG_ARCH_MULTI_V4T=y +# CONFIG_ARCH_MULTI_V7 is not set +CONFIG_KEYBOARD_GPIO_POLLED=y +CONFIG_ARCH_MOXART=y +CONFIG_MACH_UC7112LX=y +# CONFIG_ARM_THUMB is not set +CONFIG_PREEMPT=y +CONFIG_AEABI=y +# CONFIG_ATAGS is not set +CONFIG_ARM_APPENDED_DTB=y +CONFIG_NET=y +CONFIG_UNIX=y +CONFIG_INET=y +CONFIG_IP_PNP=y +CONFIG_IP_PNP_DHCP=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_INET_DIAG is not set +# CONFIG_IPV6 is not set +# CONFIG_WIRELESS is not set +CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" +CONFIG_DEVTMPFS=y +CONFIG_DEVTMPFS_MOUNT=y +# CONFIG_PREVENT_FIRMWARE_BUILD is not set +# CONFIG_FW_LOADER is not set +CONFIG_MTD=y +CONFIG_MTD_BLOCK=y +CONFIG_MTD_CFI=y +CONFIG_MTD_CFI_ADV_OPTIONS=y +CONFIG_MTD_CFI_GEOMETRY=y +CONFIG_MTD_CFI_INTELEXT=y +CONFIG_MTD_COMPLEX_MAPPINGS=y +CONFIG_MTD_PHYSMAP=y +CONFIG_MTD_PHYSMAP_OF=y +CONFIG_PROC_DEVICETREE=y +CONFIG_NETDEVICES=y +CONFIG_NETCONSOLE=y +CONFIG_NETCONSOLE_DYNAMIC=y +# CONFIG_NET_VENDOR_ARC is not set +# CONFIG_NET_CADENCE is not set +# CONFIG_NET_VENDOR_BROADCOM is not set +# CONFIG_NET_VENDOR_CIRRUS is not set +# CONFIG_NET_VENDOR_FARADAY is not set +# CONFIG_NET_VENDOR_INTEL is not set +# CONFIG_NET_VENDOR_MARVELL is not set +# CONFIG_NET_VENDOR_MICREL is not set +CONFIG_ARM_MOXART_ETHER=y +# CONFIG_NET_VENDOR_NATSEMI is not set +# CONFIG_NET_VENDOR_SEEQ is not set +# CONFIG_NET_VENDOR_SMSC is not set +# CONFIG_NET_VENDOR_STMICRO is not set +# CONFIG_NET_VENDOR_VIA is not set +# CONFIG_NET_VENDOR_WIZNET is not set +CONFIG_REALTEK_PHY=y +CONFIG_MDIO_MOXART=y +# CONFIG_WLAN is not set +# CONFIG_INPUT_MOUSEDEV is not set +CONFIG_INPUT_EVDEV=y +CONFIG_INPUT_EVBUG=y +# CONFIG_KEYBOARD_ATKBD is not set +# CONFIG_INPUT_MOUSE is not set +# 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_NR_UARTS=1 +CONFIG_SERIAL_8250_RUNTIME_UARTS=1 +CONFIG_SERIAL_8250_EXTENDED=y +CONFIG_SERIAL_8250_SHARE_IRQ=y +CONFIG_SERIAL_OF_PLATFORM=y +# CONFIG_HW_RANDOM is not set +CONFIG_DEBUG_GPIO=y +CONFIG_GPIO_SYSFS=y +CONFIG_GPIO_MOXART=y +CONFIG_POWER_SUPPLY=y +CONFIG_POWER_RESET=y +CONFIG_POWER_RESET_GPIO=y +# CONFIG_HWMON is not set +CONFIG_WATCHDOG=y +CONFIG_WATCHDOG_CORE=y +CONFIG_WATCHDOG_NOWAYOUT=y +CONFIG_MOXART_WDT=y +# CONFIG_USB_SUPPORT is not set +CONFIG_MMC=y +CONFIG_MMC_SDHCI_MOXART=y +CONFIG_NEW_LEDS=y +CONFIG_LEDS_CLASS=y +CONFIG_LEDS_GPIO=y +CONFIG_LEDS_TRIGGER_TIMER=y +CONFIG_LEDS_TRIGGER_ONESHOT=y +CONFIG_LEDS_TRIGGER_HEARTBEAT=y +CONFIG_LEDS_TRIGGER_DEFAULT_ON=y +CONFIG_RTC_CLASS=y +CONFIG_RTC_DRV_MOXART=y +CONFIG_DMADEVICES=y +CONFIG_MOXART_DMA=y +# CONFIG_IOMMU_SUPPORT is not set +CONFIG_EXT3_FS=y +CONFIG_TMPFS=y +CONFIG_CONFIGFS_FS=y +CONFIG_JFFS2_FS=y +CONFIG_PRINTK_TIME=y +CONFIG_DEBUG_INFO=y +# CONFIG_ENABLE_WARN_DEPRECATED is not set +# CONFIG_ENABLE_MUST_CHECK is not set +CONFIG_DEBUG_PAGEALLOC=y +CONFIG_DEBUG_OBJECTS=y +CONFIG_DEBUG_KMEMLEAK=y +CONFIG_DEBUG_STACK_USAGE=y +CONFIG_DEBUG_MEMORY_INIT=y +CONFIG_DEBUG_SHIRQ=y +CONFIG_DETECT_HUNG_TASK=y +# CONFIG_SCHED_DEBUG is not set +# CONFIG_DEBUG_PREEMPT is not set +CONFIG_PROVE_LOCKING=y +CONFIG_DMA_API_DEBUG=y +CONFIG_KGDB=y +CONFIG_DEBUG_LL=y +CONFIG_DEBUG_LL_UART_8250=y +CONFIG_DEBUG_UART_PHYS=0x98200000 +CONFIG_DEBUG_UART_VIRT=0xf9820000 +CONFIG_EARLY_PRINTK=y +CONFIG_KEYS=y +CONFIG_CRC32_BIT=y diff --git a/arch/arm/mach-moxart/Kconfig b/arch/arm/mach-moxart/Kconfig new file mode 100644 index 0000000..ba470d6 --- /dev/null +++ b/arch/arm/mach-moxart/Kconfig @@ -0,0 +1,31 @@ +config ARCH_MOXART + bool "MOXA ART SoC" if ARCH_MULTI_V4T + select CPU_FA526 + select ARM_DMA_MEM_BUFFERABLE + select DMA_OF + select USE_OF + select CLKSRC_OF + select CLKSRC_MMIO + select HAVE_CLK + select COMMON_CLK + select GENERIC_IRQ_CHIP + select ARCH_REQUIRE_GPIOLIB + select GENERIC_CLOCKEVENTS + select PHYLIB if NETDEVICES + help + Say Y here if you want to run your kernel on hardware with a + MOXA ART SoC. + The MOXA ART SoC is based on a Faraday FA526 ARMv4 32-bit + 192 MHz CPU with MMU and 16KB/8KB D/I-cache (UC-7112-LX). + Used on models UC-7101, UC-7112/UC-7110, IA240/IA241, IA3341. + +if ARCH_MOXART + +config MACH_UC7112LX + bool "MOXA UC-7112-LX" + depends on ARCH_MOXART + help + Say Y here if you intend to run this kernel on a MOXA + UC-7112-LX embedded computer. + +endif diff --git a/arch/arm/mach-moxart/Makefile b/arch/arm/mach-moxart/Makefile new file mode 100644 index 0000000..fa022eb --- /dev/null +++ b/arch/arm/mach-moxart/Makefile @@ -0,0 +1,3 @@ +# Object file lists. + +obj-$(CONFIG_MACH_UC7112LX) += moxart.o diff --git a/arch/arm/mach-moxart/moxart.c b/arch/arm/mach-moxart/moxart.c new file mode 100644 index 0000000..491458a --- /dev/null +++ b/arch/arm/mach-moxart/moxart.c @@ -0,0 +1,75 @@ +/* + * arch/arm/mach-moxart/moxart.c + * + * (C) Copyright 2013, Jonas Jensen <jonas.jensen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include <linux/init.h> +#include <linux/of_platform.h> +#include <linux/of_address.h> +#include <linux/io.h> + +#include <asm/mach/arch.h> +#include <asm/system_misc.h> + +#define REG_COUNT 0x4 +#define REG_MODE 0x8 +#define REG_ENABLE 0xC + +static void __iomem *moxart_wdt_base; + +static void moxart_wdt_restart(enum reboot_mode reboot_mode, const char *cmd) +{ + writel(1, moxart_wdt_base + REG_COUNT); + writel(0x5ab9, moxart_wdt_base + REG_MODE); + writel(0x03, moxart_wdt_base + REG_ENABLE); +} + +static const struct of_device_id moxart_watchdog_match[] = { + { .compatible = "moxa,moxart-watchdog", .data = moxart_wdt_restart }, + { }, +}; + +static void moxart_setup_restart(void) +{ + const struct of_device_id *of_id; + struct device_node *np; + + np = of_find_matching_node(NULL, moxart_watchdog_match); + if (WARN(!np, "unable to setup watchdog restart")) + return; + + moxart_wdt_base = of_iomap(np, 0); + WARN(!moxart_wdt_base, "failed to map watchdog base address"); + + of_id = of_match_node(moxart_watchdog_match, np); + WARN(!of_id, "restart function not available"); + + arm_pm_restart = of_id->data; +} + +static void __init moxart_dt_init(void) +{ + moxart_setup_restart(); + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); +} + +static const char * const moxart_dt_compat[] = { + "moxa,moxart", + NULL, +}; + +DT_MACHINE_START(MOXART, "MOXA UC-7112-LX") + .init_machine = moxart_dt_init, + .dt_compat = moxart_dt_compat, +MACHINE_END -- 1.8.2.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply related [flat|nested] 44+ messages in thread
* Re: [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files 2013-12-13 14:33 ` Jonas Jensen @ 2013-12-13 16:17 ` Arnd Bergmann -1 siblings, 0 replies; 44+ messages in thread From: Arnd Bergmann @ 2013-12-13 16:17 UTC (permalink / raw) To: Jonas Jensen Cc: linux-arm-kernel, linux-kernel, devicetree-discuss, arm, linux, olof On Friday 13 December 2013, Jonas Jensen wrote: > The MOXA ART SoC is based on Faraday's FA526. This is a ARMv4 32-bit > 192 MHz CPU with MMU and 16KB/8KB D/I-cache. > > Add platform support for this SoC. > > Also add UC-7112-LX as a machine. > > Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com> Let's make sure we get this merged this time. I'm definitely fine with this version going in. My questions are just for clarification on my part for potential future follow-ups. Acked-by: Arnd Bergmann <arnd@arndb.de> > diff --git a/arch/arm/configs/moxart_defconfig b/arch/arm/configs/moxart_defconfig > new file mode 100644 > index 0000000..51f0f03 > --- /dev/null > +++ b/arch/arm/configs/moxart_defconfig > @@ -0,0 +1,148 @@ > +# CONFIG_LOCALVERSION_AUTO is not set > +# CONFIG_SWAP is not set > +CONFIG_SYSVIPC=y > +CONFIG_NO_HZ=y > +CONFIG_IKCONFIG=y IIRC the separate defconfig is needed because we have never gotten a mixed fa526+arm9 kernel to boot, right? In theory it is supposed to work and there is most likely just a small bug somewhere. Once that is working, we can think about adding a generic multi_v4_v5_defconfig that handles all multipltform capable platforms along the lines of multi_v7_defconfig. > +static void __init moxart_dt_init(void) > +{ > + moxart_setup_restart(); > + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); > +} I've been out of the loop a bit here. I initially suggested having the restart handler be part of the watchdog driver, and I thought you had done that in an earlier version. What has changed your mind? Arnd ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files @ 2013-12-13 16:17 ` Arnd Bergmann 0 siblings, 0 replies; 44+ messages in thread From: Arnd Bergmann @ 2013-12-13 16:17 UTC (permalink / raw) To: linux-arm-kernel On Friday 13 December 2013, Jonas Jensen wrote: > The MOXA ART SoC is based on Faraday's FA526. This is a ARMv4 32-bit > 192 MHz CPU with MMU and 16KB/8KB D/I-cache. > > Add platform support for this SoC. > > Also add UC-7112-LX as a machine. > > Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com> Let's make sure we get this merged this time. I'm definitely fine with this version going in. My questions are just for clarification on my part for potential future follow-ups. Acked-by: Arnd Bergmann <arnd@arndb.de> > diff --git a/arch/arm/configs/moxart_defconfig b/arch/arm/configs/moxart_defconfig > new file mode 100644 > index 0000000..51f0f03 > --- /dev/null > +++ b/arch/arm/configs/moxart_defconfig > @@ -0,0 +1,148 @@ > +# CONFIG_LOCALVERSION_AUTO is not set > +# CONFIG_SWAP is not set > +CONFIG_SYSVIPC=y > +CONFIG_NO_HZ=y > +CONFIG_IKCONFIG=y IIRC the separate defconfig is needed because we have never gotten a mixed fa526+arm9 kernel to boot, right? In theory it is supposed to work and there is most likely just a small bug somewhere. Once that is working, we can think about adding a generic multi_v4_v5_defconfig that handles all multipltform capable platforms along the lines of multi_v7_defconfig. > +static void __init moxart_dt_init(void) > +{ > + moxart_setup_restart(); > + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); > +} I've been out of the loop a bit here. I initially suggested having the restart handler be part of the watchdog driver, and I thought you had done that in an earlier version. What has changed your mind? Arnd ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files 2013-12-13 16:17 ` Arnd Bergmann @ 2013-12-13 17:23 ` Jonas Jensen -1 siblings, 0 replies; 44+ messages in thread From: Jonas Jensen @ 2013-12-13 17:23 UTC (permalink / raw) To: Arnd Bergmann Cc: linux-arm-kernel, linux-kernel, devicetree-discuss, arm, Russell King - ARM Linux, Olof Johansson, linux On 13 December 2013 17:17, Arnd Bergmann <arnd@arndb.de> wrote: > IIRC the separate defconfig is needed because we have never gotten a mixed fa526+arm9 > kernel to boot, right? In theory it is supposed to work and there is most likely just > a small bug somewhere. Once that is working, we can think about adding a generic > multi_v4_v5_defconfig that handles all multipltform capable platforms along the lines > of multi_v7_defconfig. A mixed kernel can boot without panic (tested today). The panic is avoided when CONFIG_ARM_THUMB=y is removed. See thread "[PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option": http://lists.infradead.org/pipermail/linux-arm-kernel/2013-December/219004.html > I've been out of the loop a bit here. I initially suggested having the restart > handler be part of the watchdog driver, and I thought you had done that in an > earlier version. What has changed your mind? I got the impression from Guenter Roeck's review, that it doesn't belong there, maybe I was too quick to remove it? See thread "[PATCH] watchdog: Add MOXA ART watchdog driver": http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/183065.html Thanks, Jonas ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files @ 2013-12-13 17:23 ` Jonas Jensen 0 siblings, 0 replies; 44+ messages in thread From: Jonas Jensen @ 2013-12-13 17:23 UTC (permalink / raw) To: linux-arm-kernel On 13 December 2013 17:17, Arnd Bergmann <arnd@arndb.de> wrote: > IIRC the separate defconfig is needed because we have never gotten a mixed fa526+arm9 > kernel to boot, right? In theory it is supposed to work and there is most likely just > a small bug somewhere. Once that is working, we can think about adding a generic > multi_v4_v5_defconfig that handles all multipltform capable platforms along the lines > of multi_v7_defconfig. A mixed kernel can boot without panic (tested today). The panic is avoided when CONFIG_ARM_THUMB=y is removed. See thread "[PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option": http://lists.infradead.org/pipermail/linux-arm-kernel/2013-December/219004.html > I've been out of the loop a bit here. I initially suggested having the restart > handler be part of the watchdog driver, and I thought you had done that in an > earlier version. What has changed your mind? I got the impression from Guenter Roeck's review, that it doesn't belong there, maybe I was too quick to remove it? See thread "[PATCH] watchdog: Add MOXA ART watchdog driver": http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/183065.html Thanks, Jonas ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files 2013-12-13 17:23 ` Jonas Jensen @ 2013-12-13 19:07 ` Guenter Roeck -1 siblings, 0 replies; 44+ messages in thread From: Guenter Roeck @ 2013-12-13 19:07 UTC (permalink / raw) To: Jonas Jensen Cc: Arnd Bergmann, linux-arm-kernel, linux-kernel, devicetree-discuss, arm, Russell King - ARM Linux, Olof Johansson On Fri, Dec 13, 2013 at 06:23:44PM +0100, Jonas Jensen wrote: > On 13 December 2013 17:17, Arnd Bergmann <arnd@arndb.de> wrote: > > IIRC the separate defconfig is needed because we have never gotten a mixed fa526+arm9 > > kernel to boot, right? In theory it is supposed to work and there is most likely just > > a small bug somewhere. Once that is working, we can think about adding a generic > > multi_v4_v5_defconfig that handles all multipltform capable platforms along the lines > > of multi_v7_defconfig. > > A mixed kernel can boot without panic (tested today). > > The panic is avoided when CONFIG_ARM_THUMB=y is removed. > > See thread "[PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option": > > http://lists.infradead.org/pipermail/linux-arm-kernel/2013-December/219004.html > > > > I've been out of the loop a bit here. I initially suggested having the restart > > handler be part of the watchdog driver, and I thought you had done that in an > > earlier version. What has changed your mind? > > I got the impression from Guenter Roeck's review, that it doesn't belong there, > maybe I was too quick to remove it? > You'd have to answer the questions I raised in my review if you want it in there. Guenter > See thread "[PATCH] watchdog: Add MOXA ART watchdog driver": > > http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/183065.html > > > Thanks, > Jonas > ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files @ 2013-12-13 19:07 ` Guenter Roeck 0 siblings, 0 replies; 44+ messages in thread From: Guenter Roeck @ 2013-12-13 19:07 UTC (permalink / raw) To: linux-arm-kernel On Fri, Dec 13, 2013 at 06:23:44PM +0100, Jonas Jensen wrote: > On 13 December 2013 17:17, Arnd Bergmann <arnd@arndb.de> wrote: > > IIRC the separate defconfig is needed because we have never gotten a mixed fa526+arm9 > > kernel to boot, right? In theory it is supposed to work and there is most likely just > > a small bug somewhere. Once that is working, we can think about adding a generic > > multi_v4_v5_defconfig that handles all multipltform capable platforms along the lines > > of multi_v7_defconfig. > > A mixed kernel can boot without panic (tested today). > > The panic is avoided when CONFIG_ARM_THUMB=y is removed. > > See thread "[PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option": > > http://lists.infradead.org/pipermail/linux-arm-kernel/2013-December/219004.html > > > > I've been out of the loop a bit here. I initially suggested having the restart > > handler be part of the watchdog driver, and I thought you had done that in an > > earlier version. What has changed your mind? > > I got the impression from Guenter Roeck's review, that it doesn't belong there, > maybe I was too quick to remove it? > You'd have to answer the questions I raised in my review if you want it in there. Guenter > See thread "[PATCH] watchdog: Add MOXA ART watchdog driver": > > http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/183065.html > > > Thanks, > Jonas > ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files 2013-12-13 19:07 ` Guenter Roeck @ 2013-12-14 4:01 ` Arnd Bergmann -1 siblings, 0 replies; 44+ messages in thread From: Arnd Bergmann @ 2013-12-14 4:01 UTC (permalink / raw) To: Guenter Roeck Cc: Jonas Jensen, linux-arm-kernel, linux-kernel, devicetree-discuss, arm, Russell King - ARM Linux, Olof Johansson On Friday 13 December 2013, Guenter Roeck wrote: > On Fri, Dec 13, 2013 at 06:23:44PM +0100, Jonas Jensen wrote: > > On 13 December 2013 17:17, Arnd Bergmann <arnd@arndb.de> wrote: > > > I've been out of the loop a bit here. I initially suggested having the restart > > > handler be part of the watchdog driver, and I thought you had done that in an > > > earlier version. What has changed your mind? > > > > I got the impression from Guenter Roeck's review, that it doesn't belong there, > > maybe I was too quick to remove it? > > > You'd have to answer the questions I raised in my review if you want it in > there. > Let me reply to your comment from that email: > > + > > + arm_pm_restart = moxart_wdt_restart; > > It is quite unusual that system restart code is implemented in a watchdog > driver (which may not even be compiled into an image, or not be loaded). I had asked Jonas to do it in the watchdog driver because that driver is the place that handles this particular register. We have moved a bunch of restart handlers into drivers/power for similar reasons, and those can also be compiled out. The restart handler isn't actually essential for most operations, and we have moved some far more important drivers from arch/arm into drivers/, such as clocks, interrupts, timers etc. The restart handler in this case is the only piece of code that remains in mach-moxart, and I would really like it to be completely empty. Arnd ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files @ 2013-12-14 4:01 ` Arnd Bergmann 0 siblings, 0 replies; 44+ messages in thread From: Arnd Bergmann @ 2013-12-14 4:01 UTC (permalink / raw) To: linux-arm-kernel On Friday 13 December 2013, Guenter Roeck wrote: > On Fri, Dec 13, 2013 at 06:23:44PM +0100, Jonas Jensen wrote: > > On 13 December 2013 17:17, Arnd Bergmann <arnd@arndb.de> wrote: > > > I've been out of the loop a bit here. I initially suggested having the restart > > > handler be part of the watchdog driver, and I thought you had done that in an > > > earlier version. What has changed your mind? > > > > I got the impression from Guenter Roeck's review, that it doesn't belong there, > > maybe I was too quick to remove it? > > > You'd have to answer the questions I raised in my review if you want it in > there. > Let me reply to your comment from that email: > > + > > + arm_pm_restart = moxart_wdt_restart; > > It is quite unusual that system restart code is implemented in a watchdog > driver (which may not even be compiled into an image, or not be loaded). I had asked Jonas to do it in the watchdog driver because that driver is the place that handles this particular register. We have moved a bunch of restart handlers into drivers/power for similar reasons, and those can also be compiled out. The restart handler isn't actually essential for most operations, and we have moved some far more important drivers from arch/arm into drivers/, such as clocks, interrupts, timers etc. The restart handler in this case is the only piece of code that remains in mach-moxart, and I would really like it to be completely empty. Arnd ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files 2013-12-13 19:07 ` Guenter Roeck @ 2013-12-14 8:32 ` Jonas Jensen -1 siblings, 0 replies; 44+ messages in thread From: Jonas Jensen @ 2013-12-14 8:32 UTC (permalink / raw) To: Guenter Roeck Cc: Arnd Bergmann, linux-arm-kernel, linux-kernel, arm, Russell King - ARM Linux, Olof Johansson On 13 December 2013 20:07, Guenter Roeck <linux@roeck-us.net> wrote: >> I got the impression from Guenter Roeck's review, that it doesn't belong there, >> maybe I was too quick to remove it? >> > You'd have to answer the questions I raised in my review if you want it in > there. I didn't see a solution at the time. Now I'm thinking arm_pm_restart can be set later in probe, preventing a crash on load failure, and maybe it can be unset on unload. Would you accept a patch for this? Best regards, Jonas ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files @ 2013-12-14 8:32 ` Jonas Jensen 0 siblings, 0 replies; 44+ messages in thread From: Jonas Jensen @ 2013-12-14 8:32 UTC (permalink / raw) To: linux-arm-kernel On 13 December 2013 20:07, Guenter Roeck <linux@roeck-us.net> wrote: >> I got the impression from Guenter Roeck's review, that it doesn't belong there, >> maybe I was too quick to remove it? >> > You'd have to answer the questions I raised in my review if you want it in > there. I didn't see a solution at the time. Now I'm thinking arm_pm_restart can be set later in probe, preventing a crash on load failure, and maybe it can be unset on unload. Would you accept a patch for this? Best regards, Jonas ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files 2013-12-14 8:32 ` Jonas Jensen @ 2013-12-14 15:50 ` Guenter Roeck -1 siblings, 0 replies; 44+ messages in thread From: Guenter Roeck @ 2013-12-14 15:50 UTC (permalink / raw) To: Jonas Jensen Cc: Arnd Bergmann, linux-arm-kernel, linux-kernel, arm, Russell King - ARM Linux, Olof Johansson On 12/14/2013 12:32 AM, Jonas Jensen wrote: > On 13 December 2013 20:07, Guenter Roeck <linux@roeck-us.net> wrote: >>> I got the impression from Guenter Roeck's review, that it doesn't belong there, >>> maybe I was too quick to remove it? >>> >> You'd have to answer the questions I raised in my review if you want it in >> there. > > I didn't see a solution at the time. Now I'm thinking arm_pm_restart > can be set later in probe, preventing a crash on load failure, and > maybe it can be unset on unload. > > Would you accept a patch for this? > The above would at least avoid the crash, though I would not understand the point of having an unloadable restart handler. Forcing the watchdog driver into the kernel just because you want the restart handler in it would seem odd. And if the restart handler is optional, why have it in the first place ? I also don't follow Arnd's logic of wanting to have the code in the watchdog driver just because it happens to use a register that it needs. Conceptually it might be cleaner to write a separate driver, for example in drivers/power/restart, than plugging the functionality into the watchdog driver, at least if you don't want it in architecture or platform code. The xgene restart driver is a good example. Anyway, it is not up to me to accept the code, that is up to Wim. My rejection was primarily due to technical flaws, which can be addressed. For the logical reasoning you'll have to convince Wim. Guenter ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files @ 2013-12-14 15:50 ` Guenter Roeck 0 siblings, 0 replies; 44+ messages in thread From: Guenter Roeck @ 2013-12-14 15:50 UTC (permalink / raw) To: linux-arm-kernel On 12/14/2013 12:32 AM, Jonas Jensen wrote: > On 13 December 2013 20:07, Guenter Roeck <linux@roeck-us.net> wrote: >>> I got the impression from Guenter Roeck's review, that it doesn't belong there, >>> maybe I was too quick to remove it? >>> >> You'd have to answer the questions I raised in my review if you want it in >> there. > > I didn't see a solution at the time. Now I'm thinking arm_pm_restart > can be set later in probe, preventing a crash on load failure, and > maybe it can be unset on unload. > > Would you accept a patch for this? > The above would at least avoid the crash, though I would not understand the point of having an unloadable restart handler. Forcing the watchdog driver into the kernel just because you want the restart handler in it would seem odd. And if the restart handler is optional, why have it in the first place ? I also don't follow Arnd's logic of wanting to have the code in the watchdog driver just because it happens to use a register that it needs. Conceptually it might be cleaner to write a separate driver, for example in drivers/power/restart, than plugging the functionality into the watchdog driver, at least if you don't want it in architecture or platform code. The xgene restart driver is a good example. Anyway, it is not up to me to accept the code, that is up to Wim. My rejection was primarily due to technical flaws, which can be addressed. For the logical reasoning you'll have to convince Wim. Guenter ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files 2013-12-14 15:50 ` Guenter Roeck @ 2013-12-14 16:26 ` Jonas Jensen -1 siblings, 0 replies; 44+ messages in thread From: Jonas Jensen @ 2013-12-14 16:26 UTC (permalink / raw) To: Guenter Roeck Cc: Arnd Bergmann, linux-arm-kernel, linux-kernel, arm, Russell King - ARM Linux, Olof Johansson On 14 December 2013 16:50, Guenter Roeck <linux@roeck-us.net> wrote: > The above would at least avoid the crash, though I would not understand > the point of having an unloadable restart handler. Forcing the watchdog > driver into the kernel just because you want the restart handler in it > would seem odd. And if the restart handler is optional, why have it > in the first place ? I also don't follow Arnd's logic of wanting to have > the code in the watchdog driver just because it happens to use a register > that it needs. > > Conceptually it might be cleaner to write a separate driver, for example > in drivers/power/restart, than plugging the functionality into > the watchdog driver, at least if you don't want it in architecture > or platform code. The xgene restart driver is a good example. > > Anyway, it is not up to me to accept the code, that is up to Wim. > My rejection was primarily due to technical flaws, which can be addressed. > For the logical reasoning you'll have to convince Wim. Thanks for the replies. Moving it to a new power/restart driver seems reasonable to me, I'm really just looking for a home for it, I would have preferred a hardware with reset in a separate register though. I now plan to remove it for v5 and submit a separate driver. Regards, Jonas ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files @ 2013-12-14 16:26 ` Jonas Jensen 0 siblings, 0 replies; 44+ messages in thread From: Jonas Jensen @ 2013-12-14 16:26 UTC (permalink / raw) To: linux-arm-kernel On 14 December 2013 16:50, Guenter Roeck <linux@roeck-us.net> wrote: > The above would at least avoid the crash, though I would not understand > the point of having an unloadable restart handler. Forcing the watchdog > driver into the kernel just because you want the restart handler in it > would seem odd. And if the restart handler is optional, why have it > in the first place ? I also don't follow Arnd's logic of wanting to have > the code in the watchdog driver just because it happens to use a register > that it needs. > > Conceptually it might be cleaner to write a separate driver, for example > in drivers/power/restart, than plugging the functionality into > the watchdog driver, at least if you don't want it in architecture > or platform code. The xgene restart driver is a good example. > > Anyway, it is not up to me to accept the code, that is up to Wim. > My rejection was primarily due to technical flaws, which can be addressed. > For the logical reasoning you'll have to convince Wim. Thanks for the replies. Moving it to a new power/restart driver seems reasonable to me, I'm really just looking for a home for it, I would have preferred a hardware with reset in a separate register though. I now plan to remove it for v5 and submit a separate driver. Regards, Jonas ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files 2013-12-14 16:26 ` Jonas Jensen @ 2013-12-14 18:50 ` Arnd Bergmann -1 siblings, 0 replies; 44+ messages in thread From: Arnd Bergmann @ 2013-12-14 18:50 UTC (permalink / raw) To: Jonas Jensen Cc: Guenter Roeck, linux-arm-kernel, linux-kernel, arm, Russell King - ARM Linux, Olof Johansson On Saturday 14 December 2013, Jonas Jensen wrote: > > > > Conceptually it might be cleaner to write a separate driver, for example > > in drivers/power/restart, than plugging the functionality into > > the watchdog driver, at least if you don't want it in architecture > > or platform code. The xgene restart driver is a good example. > > > > Moving it to a new power/restart driver seems reasonable to me, I'm > really just looking for a home for it, I would have preferred a > hardware with reset in a separate register though. > > I now plan to remove it for v5 and submit a separate driver. I still think it's better to leave it in the watchdog driver: This driver attaches to the watchdog device, and adding a separate driver for reset means we have to trick the core Linux code into attaching two drivers to one device in some way, or the device tree has to fake a second device that doesn't exist in hardware but is only needed because of Linux implementation details. Arnd ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files @ 2013-12-14 18:50 ` Arnd Bergmann 0 siblings, 0 replies; 44+ messages in thread From: Arnd Bergmann @ 2013-12-14 18:50 UTC (permalink / raw) To: linux-arm-kernel On Saturday 14 December 2013, Jonas Jensen wrote: > > > > Conceptually it might be cleaner to write a separate driver, for example > > in drivers/power/restart, than plugging the functionality into > > the watchdog driver, at least if you don't want it in architecture > > or platform code. The xgene restart driver is a good example. > > > > Moving it to a new power/restart driver seems reasonable to me, I'm > really just looking for a home for it, I would have preferred a > hardware with reset in a separate register though. > > I now plan to remove it for v5 and submit a separate driver. I still think it's better to leave it in the watchdog driver: This driver attaches to the watchdog device, and adding a separate driver for reset means we have to trick the core Linux code into attaching two drivers to one device in some way, or the device tree has to fake a second device that doesn't exist in hardware but is only needed because of Linux implementation details. Arnd ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files 2013-12-14 18:50 ` Arnd Bergmann @ 2013-12-14 20:14 ` Guenter Roeck -1 siblings, 0 replies; 44+ messages in thread From: Guenter Roeck @ 2013-12-14 20:14 UTC (permalink / raw) To: Arnd Bergmann, Jonas Jensen Cc: linux-arm-kernel, linux-kernel, arm, Russell King - ARM Linux, Olof Johansson On 12/14/2013 10:50 AM, Arnd Bergmann wrote: > On Saturday 14 December 2013, Jonas Jensen wrote: >>> >>> Conceptually it might be cleaner to write a separate driver, for example >>> in drivers/power/restart, than plugging the functionality into >>> the watchdog driver, at least if you don't want it in architecture >>> or platform code. The xgene restart driver is a good example. >>> >> >> Moving it to a new power/restart driver seems reasonable to me, I'm >> really just looking for a home for it, I would have preferred a >> hardware with reset in a separate register though. >> >> I now plan to remove it for v5 and submit a separate driver. > > I still think it's better to leave it in the watchdog driver: This > driver attaches to the watchdog device, and adding a separate driver > for reset means we have to trick the core Linux code into attaching > two drivers to one device in some way, or the device tree has to fake > a second device that doesn't exist in hardware but is only needed > because of Linux implementation details. > Hmm ... not sure I agree. I don't see a problem with something like "arm,moxart-reboot". There are already vexpress-reboot and xgene-reboot properties which do pretty much the same. Actually, you don't even need that; the reset driver could simply re-use the "moxa,moxart-watchdog" property. After all, all that specifies is that there is a compatible driver. Look for "samsung,s3c2410-wdt" for an example of another reset handler doing just that. Attaching it to the watchdog device seems to be more problematic given the (currently) optional nature of the watchdog driver and its different scope. Thanks, Guenter ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files @ 2013-12-14 20:14 ` Guenter Roeck 0 siblings, 0 replies; 44+ messages in thread From: Guenter Roeck @ 2013-12-14 20:14 UTC (permalink / raw) To: linux-arm-kernel On 12/14/2013 10:50 AM, Arnd Bergmann wrote: > On Saturday 14 December 2013, Jonas Jensen wrote: >>> >>> Conceptually it might be cleaner to write a separate driver, for example >>> in drivers/power/restart, than plugging the functionality into >>> the watchdog driver, at least if you don't want it in architecture >>> or platform code. The xgene restart driver is a good example. >>> >> >> Moving it to a new power/restart driver seems reasonable to me, I'm >> really just looking for a home for it, I would have preferred a >> hardware with reset in a separate register though. >> >> I now plan to remove it for v5 and submit a separate driver. > > I still think it's better to leave it in the watchdog driver: This > driver attaches to the watchdog device, and adding a separate driver > for reset means we have to trick the core Linux code into attaching > two drivers to one device in some way, or the device tree has to fake > a second device that doesn't exist in hardware but is only needed > because of Linux implementation details. > Hmm ... not sure I agree. I don't see a problem with something like "arm,moxart-reboot". There are already vexpress-reboot and xgene-reboot properties which do pretty much the same. Actually, you don't even need that; the reset driver could simply re-use the "moxa,moxart-watchdog" property. After all, all that specifies is that there is a compatible driver. Look for "samsung,s3c2410-wdt" for an example of another reset handler doing just that. Attaching it to the watchdog device seems to be more problematic given the (currently) optional nature of the watchdog driver and its different scope. Thanks, Guenter ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files 2013-12-14 20:14 ` Guenter Roeck @ 2013-12-15 0:21 ` Arnd Bergmann -1 siblings, 0 replies; 44+ messages in thread From: Arnd Bergmann @ 2013-12-15 0:21 UTC (permalink / raw) To: Guenter Roeck Cc: Jonas Jensen, linux-arm-kernel, linux-kernel, arm, Russell King - ARM Linux, Olof Johansson On Saturday 14 December 2013, Guenter Roeck wrote: > Hmm ... not sure I agree. I don't see a problem with something like "arm,moxart-reboot". > There are already vexpress-reboot and xgene-reboot properties which do pretty much > the same. > > Actually, you don't even need that; the reset driver could simply re-use the > "moxa,moxart-watchdog" property. After all, all that specifies is that there > is a compatible driver. Look for "samsung,s3c2410-wdt" for an example of another > reset handler doing just that. > > Attaching it to the watchdog device seems to be more problematic given the > (currently) optional nature of the watchdog driver and its different scope. As far as I'm concerned a watchdog driver is just as optional as a reboot driver. The vexpress and xgene reset drivers are different because those are actually dedicated devices that are there only to do rebooting. The "samsung,s3c2410-wdt" device is exactly the same category as the moxart one, but the code to use it performs the same hack by scanning the device tree ad hoc from the platform initialization. I think it should be integrated into watchdog the same way, and if we have more drivers in that category, we'd probably want a generic watchdog reboot callback function that wdt drivers can hook up to the architecture reset handler. The main difference I see between plat-samsung and mach-moxart here is that the samsung platforms still need a lot of code in arch/arm to get things to work (this will have to change as soon as we get an arm64 exynos, which would have everything in proper drivers), while for moxart this is the only non-driver code. Reusing the moxa,moxart-watchdog device from a separate reboot driver is a violation of the driver model, since we can't really bind two platform drivers to one platform device, unless you add another device in drivers/mfd to create two children for wdt and reboot, but that would be really silly. You could use the same code that samsung has at the moment in a loadable module, which effectively implements a linux-2.4 style driver that probes the device in the module_init function rather than registering a struct device_driver with a probe callback. Arnd ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files @ 2013-12-15 0:21 ` Arnd Bergmann 0 siblings, 0 replies; 44+ messages in thread From: Arnd Bergmann @ 2013-12-15 0:21 UTC (permalink / raw) To: linux-arm-kernel On Saturday 14 December 2013, Guenter Roeck wrote: > Hmm ... not sure I agree. I don't see a problem with something like "arm,moxart-reboot". > There are already vexpress-reboot and xgene-reboot properties which do pretty much > the same. > > Actually, you don't even need that; the reset driver could simply re-use the > "moxa,moxart-watchdog" property. After all, all that specifies is that there > is a compatible driver. Look for "samsung,s3c2410-wdt" for an example of another > reset handler doing just that. > > Attaching it to the watchdog device seems to be more problematic given the > (currently) optional nature of the watchdog driver and its different scope. As far as I'm concerned a watchdog driver is just as optional as a reboot driver. The vexpress and xgene reset drivers are different because those are actually dedicated devices that are there only to do rebooting. The "samsung,s3c2410-wdt" device is exactly the same category as the moxart one, but the code to use it performs the same hack by scanning the device tree ad hoc from the platform initialization. I think it should be integrated into watchdog the same way, and if we have more drivers in that category, we'd probably want a generic watchdog reboot callback function that wdt drivers can hook up to the architecture reset handler. The main difference I see between plat-samsung and mach-moxart here is that the samsung platforms still need a lot of code in arch/arm to get things to work (this will have to change as soon as we get an arm64 exynos, which would have everything in proper drivers), while for moxart this is the only non-driver code. Reusing the moxa,moxart-watchdog device from a separate reboot driver is a violation of the driver model, since we can't really bind two platform drivers to one platform device, unless you add another device in drivers/mfd to create two children for wdt and reboot, but that would be really silly. You could use the same code that samsung has at the moment in a loadable module, which effectively implements a linux-2.4 style driver that probes the device in the module_init function rather than registering a struct device_driver with a probe callback. Arnd ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files 2013-12-13 14:33 ` Jonas Jensen @ 2013-12-22 19:48 ` Olof Johansson -1 siblings, 0 replies; 44+ messages in thread From: Olof Johansson @ 2013-12-22 19:48 UTC (permalink / raw) To: Jonas Jensen Cc: linux-arm-kernel, linux-kernel, devicetree-discuss, arm, linux, arnd On Fri, Dec 13, 2013 at 03:33:07PM +0100, Jonas Jensen wrote: > The MOXA ART SoC is based on Faraday's FA526. This is a ARMv4 32-bit > 192 MHz CPU with MMU and 16KB/8KB D/I-cache. > > Add platform support for this SoC. > > Also add UC-7112-LX as a machine. > > Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com> Applied to next/soc for 3.14. Please follow up on the comments and submit patches as needed on top of this. Also, I renamed the patch to be ARM: moxart: ... since we normally leave out the mach- part. -Olof ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files @ 2013-12-22 19:48 ` Olof Johansson 0 siblings, 0 replies; 44+ messages in thread From: Olof Johansson @ 2013-12-22 19:48 UTC (permalink / raw) To: linux-arm-kernel On Fri, Dec 13, 2013 at 03:33:07PM +0100, Jonas Jensen wrote: > The MOXA ART SoC is based on Faraday's FA526. This is a ARMv4 32-bit > 192 MHz CPU with MMU and 16KB/8KB D/I-cache. > > Add platform support for this SoC. > > Also add UC-7112-LX as a machine. > > Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com> Applied to next/soc for 3.14. Please follow up on the comments and submit patches as needed on top of this. Also, I renamed the patch to be ARM: moxart: ... since we normally leave out the mach- part. -Olof ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v4 2/2] ARM: mach-moxart: add MOXA ART SoC device tree files 2013-12-13 14:33 ` Jonas Jensen @ 2013-12-13 14:33 ` Jonas Jensen -1 siblings, 0 replies; 44+ messages in thread From: Jonas Jensen @ 2013-12-13 14:33 UTC (permalink / raw) To: linux-arm-kernel Cc: linux-kernel, devicetree-discuss, arm, linux, arnd, olof, Jonas Jensen Add a generic (dtsi) include file for MOXA ART SoCs. Also add a file for UC-7112-LX. Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com> --- Documentation/devicetree/bindings/arm/moxart.txt | 12 +++ arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/moxart-uc7112lx.dts | 131 +++++++++++++++++++++++ arch/arm/boot/dts/moxart.dtsi | 100 +++++++++++++++++ 4 files changed, 244 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/moxart.txt create mode 100644 arch/arm/boot/dts/moxart-uc7112lx.dts create mode 100644 arch/arm/boot/dts/moxart.dtsi diff --git a/Documentation/devicetree/bindings/arm/moxart.txt b/Documentation/devicetree/bindings/arm/moxart.txt new file mode 100644 index 0000000..11087ed --- /dev/null +++ b/Documentation/devicetree/bindings/arm/moxart.txt @@ -0,0 +1,12 @@ +MOXA ART device tree bindings + +Boards with the MOXA ART SoC shall have the following properties: + +Required root node property: + +compatible = "moxa,moxart"; + +Boards: + +- UC-7112-LX: embedded computer + compatible = "moxa,moxart-uc-7112-lx", "moxa,moxart" diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index 9fe33e7..f331b22 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -318,6 +318,7 @@ dtb-$(CONFIG_ARCH_VT8500) += vt8500-bv07.dtb \ dtb-$(CONFIG_ARCH_ZYNQ) += zynq-zc702.dtb \ zynq-zc706.dtb \ zynq-zed.dtb +dtb-$(CONFIG_ARCH_MOXART) += moxart-uc7112lx.dtb targets += dtbs targets += $(dtb-y) diff --git a/arch/arm/boot/dts/moxart-uc7112lx.dts b/arch/arm/boot/dts/moxart-uc7112lx.dts new file mode 100644 index 0000000..c63d013 --- /dev/null +++ b/arch/arm/boot/dts/moxart-uc7112lx.dts @@ -0,0 +1,131 @@ +/* moxart-uc7112lx.dts - Device Tree file for MOXA UC-7112-LX + * + * Copyright (C) 2013 Jonas Jensen <jonas.jensen@gmail.com> + * + * Licensed under GPLv2 or later. + */ + +/dts-v1/; +/include/ "moxart.dtsi" + +/ { + model = "MOXA UC-7112-LX"; + compatible = "moxa,moxart-uc-7112-lx", "moxa,moxart"; + + memory { + device_type = "memory"; + reg = <0x0 0x2000000>; + }; + + flash@80000000,0 { + compatible = "numonyx,js28f128", "cfi-flash"; + reg = <0x80000000 0x1000000>; + bank-width = <2>; + #address-cells = <1>; + #size-cells = <1>; + partition@0 { + label = "bootloader"; + reg = <0x0 0x40000>; + }; + partition@40000 { + label = "linux kernel"; + reg = <0x40000 0x1C0000>; + }; + partition@200000 { + label = "root filesystem"; + reg = <0x200000 0x800000>; + }; + partition@a00000 { + label = "user filesystem"; + reg = <0xa00000 0x600000>; + }; + }; + + sdhci: sdhci@98e00000 { + compatible = "moxa,moxart-sdhci"; + reg = <0x98e00000 0x5C>; + interrupts = <5 0>; + clocks = <&clk_apb>; + dmas = <&dma 5>, + <&dma 5>; + dma-names = "tx", "rx"; + }; + + mdio0: mdio@90900090 { + compatible = "moxa,moxart-mdio"; + reg = <0x90900090 0x8>; + #address-cells = <1>; + #size-cells = <0>; + + ethphy0: ethernet-phy@1 { + device_type = "ethernet-phy"; + compatible = "moxa,moxart-rtl8201cp", "ethernet-phy-ieee802.3-c22"; + reg = <1>; + }; + }; + + mdio1: mdio@92000090 { + compatible = "moxa,moxart-mdio"; + reg = <0x92000090 0x8>; + #address-cells = <1>; + #size-cells = <0>; + + ethphy1: ethernet-phy@1 { + device_type = "ethernet-phy"; + compatible = "moxa,moxart-rtl8201cp", "ethernet-phy-ieee802.3-c22"; + reg = <1>; + }; + }; + + mac0: mac@90900000 { + compatible = "moxa,moxart-mac"; + reg = <0x90900000 0x90>; + interrupts = <25 0>; + phy-handle = <ðphy0>; + phy-mode = "mii"; + }; + + mac1: mac@92000000 { + compatible = "moxa,moxart-mac"; + reg = <0x92000000 0x90>; + interrupts = <27 0>; + phy-handle = <ðphy1>; + phy-mode = "mii"; + }; + + uart0: uart@98200000 { + compatible = "ns16550a"; + reg = <0x98200000 0x20>; + interrupts = <31 8>; + reg-shift = <2>; + reg-io-width = <4>; + clock-frequency = <14745600>; + status = "okay"; + }; + + leds { + compatible = "gpio-leds"; + user-led { + label = "ready-led"; + gpios = <&gpio 27 0x1>; + default-state = "on"; + linux,default-trigger = "default-on"; + }; + }; + + gpio_keys_polled { + compatible = "gpio-keys-polled"; + #address-cells = <1>; + #size-cells = <0>; + poll-interval = <500>; + button@25 { + label = "GPIO Reset"; + linux,code = <116>; + gpios = <&gpio 25 1>; + }; + }; + + chosen { + bootargs = "console=ttyS0,115200n8 earlyprintk root=/dev/mmcblk0p1 rw rootwait"; + }; +}; diff --git a/arch/arm/boot/dts/moxart.dtsi b/arch/arm/boot/dts/moxart.dtsi new file mode 100644 index 0000000..0ea51ed --- /dev/null +++ b/arch/arm/boot/dts/moxart.dtsi @@ -0,0 +1,100 @@ +/* moxart.dtsi - Device Tree Include file for MOXA ART family SoC + * + * Copyright (C) 2013 Jonas Jensen <jonas.jensen@gmail.com> + * + * Licensed under GPLv2 or later. + */ + +/include/ "skeleton.dtsi" + +/ { + compatible = "moxa,moxart"; + model = "MOXART"; + interrupt-parent = <&intc>; + + cpus { + #address-cells = <1>; + #size-cells = <0>; + + cpu@0 { + device_type = "cpu"; + compatible = "faraday,fa526"; + reg = <0>; + }; + }; + + clocks { + #address-cells = <1>; + #size-cells = <0>; + + ref12: ref12M { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <12000000>; + }; + }; + + soc { + compatible = "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0x90000000 0x10000000>; + ranges; + + intc: interrupt-controller@98800000 { + compatible = "moxa,moxart-ic"; + reg = <0x98800000 0x38>; + interrupt-controller; + #interrupt-cells = <2>; + interrupt-mask = <0x00080000>; + }; + + clk_pll: clk_pll@98100000 { + compatible = "moxa,moxart-pll-clock"; + #clock-cells = <0>; + reg = <0x98100000 0x34>; + clocks = <&ref12>; + }; + + clk_apb: clk_apb@98100000 { + compatible = "moxa,moxart-apb-clock"; + #clock-cells = <0>; + reg = <0x98100000 0x34>; + clocks = <&clk_pll>; + }; + + timer: timer@98400000 { + compatible = "moxa,moxart-timer"; + reg = <0x98400000 0x42>; + interrupts = <19 1>; + clocks = <&clk_apb>; + }; + + gpio: gpio@98700000 { + gpio-controller; + #gpio-cells = <2>; + compatible = "moxa,moxart-gpio"; + reg = <0x98700000 0xC>; + }; + + rtc: rtc { + compatible = "moxa,moxart-rtc"; + gpio-rtc-sclk = <&gpio 5 0>; + gpio-rtc-data = <&gpio 6 0>; + gpio-rtc-reset = <&gpio 7 0>; + }; + + dma: dma@90500000 { + compatible = "moxa,moxart-dma"; + reg = <0x90500080 0x40>; + interrupts = <24 0>; + #dma-cells = <1>; + }; + + watchdog: watchdog@98500000 { + compatible = "moxa,moxart-watchdog"; + reg = <0x98500000 0x10>; + clocks = <&clk_apb>; + }; + }; +}; -- 1.8.2.1 ^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH v4 2/2] ARM: mach-moxart: add MOXA ART SoC device tree files @ 2013-12-13 14:33 ` Jonas Jensen 0 siblings, 0 replies; 44+ messages in thread From: Jonas Jensen @ 2013-12-13 14:33 UTC (permalink / raw) To: linux-arm-kernel Add a generic (dtsi) include file for MOXA ART SoCs. Also add a file for UC-7112-LX. Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com> --- Documentation/devicetree/bindings/arm/moxart.txt | 12 +++ arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/moxart-uc7112lx.dts | 131 +++++++++++++++++++++++ arch/arm/boot/dts/moxart.dtsi | 100 +++++++++++++++++ 4 files changed, 244 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/moxart.txt create mode 100644 arch/arm/boot/dts/moxart-uc7112lx.dts create mode 100644 arch/arm/boot/dts/moxart.dtsi diff --git a/Documentation/devicetree/bindings/arm/moxart.txt b/Documentation/devicetree/bindings/arm/moxart.txt new file mode 100644 index 0000000..11087ed --- /dev/null +++ b/Documentation/devicetree/bindings/arm/moxart.txt @@ -0,0 +1,12 @@ +MOXA ART device tree bindings + +Boards with the MOXA ART SoC shall have the following properties: + +Required root node property: + +compatible = "moxa,moxart"; + +Boards: + +- UC-7112-LX: embedded computer + compatible = "moxa,moxart-uc-7112-lx", "moxa,moxart" diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index 9fe33e7..f331b22 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -318,6 +318,7 @@ dtb-$(CONFIG_ARCH_VT8500) += vt8500-bv07.dtb \ dtb-$(CONFIG_ARCH_ZYNQ) += zynq-zc702.dtb \ zynq-zc706.dtb \ zynq-zed.dtb +dtb-$(CONFIG_ARCH_MOXART) += moxart-uc7112lx.dtb targets += dtbs targets += $(dtb-y) diff --git a/arch/arm/boot/dts/moxart-uc7112lx.dts b/arch/arm/boot/dts/moxart-uc7112lx.dts new file mode 100644 index 0000000..c63d013 --- /dev/null +++ b/arch/arm/boot/dts/moxart-uc7112lx.dts @@ -0,0 +1,131 @@ +/* moxart-uc7112lx.dts - Device Tree file for MOXA UC-7112-LX + * + * Copyright (C) 2013 Jonas Jensen <jonas.jensen@gmail.com> + * + * Licensed under GPLv2 or later. + */ + +/dts-v1/; +/include/ "moxart.dtsi" + +/ { + model = "MOXA UC-7112-LX"; + compatible = "moxa,moxart-uc-7112-lx", "moxa,moxart"; + + memory { + device_type = "memory"; + reg = <0x0 0x2000000>; + }; + + flash at 80000000,0 { + compatible = "numonyx,js28f128", "cfi-flash"; + reg = <0x80000000 0x1000000>; + bank-width = <2>; + #address-cells = <1>; + #size-cells = <1>; + partition at 0 { + label = "bootloader"; + reg = <0x0 0x40000>; + }; + partition at 40000 { + label = "linux kernel"; + reg = <0x40000 0x1C0000>; + }; + partition at 200000 { + label = "root filesystem"; + reg = <0x200000 0x800000>; + }; + partition at a00000 { + label = "user filesystem"; + reg = <0xa00000 0x600000>; + }; + }; + + sdhci: sdhci at 98e00000 { + compatible = "moxa,moxart-sdhci"; + reg = <0x98e00000 0x5C>; + interrupts = <5 0>; + clocks = <&clk_apb>; + dmas = <&dma 5>, + <&dma 5>; + dma-names = "tx", "rx"; + }; + + mdio0: mdio at 90900090 { + compatible = "moxa,moxart-mdio"; + reg = <0x90900090 0x8>; + #address-cells = <1>; + #size-cells = <0>; + + ethphy0: ethernet-phy at 1 { + device_type = "ethernet-phy"; + compatible = "moxa,moxart-rtl8201cp", "ethernet-phy-ieee802.3-c22"; + reg = <1>; + }; + }; + + mdio1: mdio at 92000090 { + compatible = "moxa,moxart-mdio"; + reg = <0x92000090 0x8>; + #address-cells = <1>; + #size-cells = <0>; + + ethphy1: ethernet-phy at 1 { + device_type = "ethernet-phy"; + compatible = "moxa,moxart-rtl8201cp", "ethernet-phy-ieee802.3-c22"; + reg = <1>; + }; + }; + + mac0: mac at 90900000 { + compatible = "moxa,moxart-mac"; + reg = <0x90900000 0x90>; + interrupts = <25 0>; + phy-handle = <ðphy0>; + phy-mode = "mii"; + }; + + mac1: mac at 92000000 { + compatible = "moxa,moxart-mac"; + reg = <0x92000000 0x90>; + interrupts = <27 0>; + phy-handle = <ðphy1>; + phy-mode = "mii"; + }; + + uart0: uart at 98200000 { + compatible = "ns16550a"; + reg = <0x98200000 0x20>; + interrupts = <31 8>; + reg-shift = <2>; + reg-io-width = <4>; + clock-frequency = <14745600>; + status = "okay"; + }; + + leds { + compatible = "gpio-leds"; + user-led { + label = "ready-led"; + gpios = <&gpio 27 0x1>; + default-state = "on"; + linux,default-trigger = "default-on"; + }; + }; + + gpio_keys_polled { + compatible = "gpio-keys-polled"; + #address-cells = <1>; + #size-cells = <0>; + poll-interval = <500>; + button at 25 { + label = "GPIO Reset"; + linux,code = <116>; + gpios = <&gpio 25 1>; + }; + }; + + chosen { + bootargs = "console=ttyS0,115200n8 earlyprintk root=/dev/mmcblk0p1 rw rootwait"; + }; +}; diff --git a/arch/arm/boot/dts/moxart.dtsi b/arch/arm/boot/dts/moxart.dtsi new file mode 100644 index 0000000..0ea51ed --- /dev/null +++ b/arch/arm/boot/dts/moxart.dtsi @@ -0,0 +1,100 @@ +/* moxart.dtsi - Device Tree Include file for MOXA ART family SoC + * + * Copyright (C) 2013 Jonas Jensen <jonas.jensen@gmail.com> + * + * Licensed under GPLv2 or later. + */ + +/include/ "skeleton.dtsi" + +/ { + compatible = "moxa,moxart"; + model = "MOXART"; + interrupt-parent = <&intc>; + + cpus { + #address-cells = <1>; + #size-cells = <0>; + + cpu at 0 { + device_type = "cpu"; + compatible = "faraday,fa526"; + reg = <0>; + }; + }; + + clocks { + #address-cells = <1>; + #size-cells = <0>; + + ref12: ref12M { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <12000000>; + }; + }; + + soc { + compatible = "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0x90000000 0x10000000>; + ranges; + + intc: interrupt-controller at 98800000 { + compatible = "moxa,moxart-ic"; + reg = <0x98800000 0x38>; + interrupt-controller; + #interrupt-cells = <2>; + interrupt-mask = <0x00080000>; + }; + + clk_pll: clk_pll at 98100000 { + compatible = "moxa,moxart-pll-clock"; + #clock-cells = <0>; + reg = <0x98100000 0x34>; + clocks = <&ref12>; + }; + + clk_apb: clk_apb at 98100000 { + compatible = "moxa,moxart-apb-clock"; + #clock-cells = <0>; + reg = <0x98100000 0x34>; + clocks = <&clk_pll>; + }; + + timer: timer at 98400000 { + compatible = "moxa,moxart-timer"; + reg = <0x98400000 0x42>; + interrupts = <19 1>; + clocks = <&clk_apb>; + }; + + gpio: gpio at 98700000 { + gpio-controller; + #gpio-cells = <2>; + compatible = "moxa,moxart-gpio"; + reg = <0x98700000 0xC>; + }; + + rtc: rtc { + compatible = "moxa,moxart-rtc"; + gpio-rtc-sclk = <&gpio 5 0>; + gpio-rtc-data = <&gpio 6 0>; + gpio-rtc-reset = <&gpio 7 0>; + }; + + dma: dma at 90500000 { + compatible = "moxa,moxart-dma"; + reg = <0x90500080 0x40>; + interrupts = <24 0>; + #dma-cells = <1>; + }; + + watchdog: watchdog at 98500000 { + compatible = "moxa,moxart-watchdog"; + reg = <0x98500000 0x10>; + clocks = <&clk_apb>; + }; + }; +}; -- 1.8.2.1 ^ permalink raw reply related [flat|nested] 44+ messages in thread
[parent not found: <1386945188-8316-3-git-send-email-jonas.jensen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]
* Fwd: [PATCH v4 2/2] ARM: mach-moxart: add MOXA ART SoC device tree files [not found] ` <1386945188-8316-3-git-send-email-jonas.jensen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> @ 2013-12-13 14:39 ` Jonas Jensen 0 siblings, 0 replies; 44+ messages in thread From: Jonas Jensen @ 2013-12-13 14:39 UTC (permalink / raw) To: devicetree-u79uwXL29TY76Z2rM5mHXA Forwarding this because I used the wrong Cc address to devicetree-u79uwXL29TaiAVqoAR/hOA@public.gmane.org ---------- Forwarded message ---------- From: Jonas Jensen <jonas.jensen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Date: 13 December 2013 15:33 Subject: [PATCH v4 2/2] ARM: mach-moxart: add MOXA ART SoC device tree files To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org, arm-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org, arnd-r2nGTMty4D4@public.gmane.org, olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org, Jonas Jensen <jonas.jensen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Add a generic (dtsi) include file for MOXA ART SoCs. Also add a file for UC-7112-LX. Signed-off-by: Jonas Jensen <jonas.jensen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> --- Documentation/devicetree/bindings/arm/moxart.txt | 12 +++ arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/moxart-uc7112lx.dts | 131 +++++++++++++++++++++++ arch/arm/boot/dts/moxart.dtsi | 100 +++++++++++++++++ 4 files changed, 244 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/moxart.txt create mode 100644 arch/arm/boot/dts/moxart-uc7112lx.dts create mode 100644 arch/arm/boot/dts/moxart.dtsi diff --git a/Documentation/devicetree/bindings/arm/moxart.txt b/Documentation/devicetree/bindings/arm/moxart.txt new file mode 100644 index 0000000..11087ed --- /dev/null +++ b/Documentation/devicetree/bindings/arm/moxart.txt @@ -0,0 +1,12 @@ +MOXA ART device tree bindings + +Boards with the MOXA ART SoC shall have the following properties: + +Required root node property: + +compatible = "moxa,moxart"; + +Boards: + +- UC-7112-LX: embedded computer + compatible = "moxa,moxart-uc-7112-lx", "moxa,moxart" diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index 9fe33e7..f331b22 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -318,6 +318,7 @@ dtb-$(CONFIG_ARCH_VT8500) += vt8500-bv07.dtb \ dtb-$(CONFIG_ARCH_ZYNQ) += zynq-zc702.dtb \ zynq-zc706.dtb \ zynq-zed.dtb +dtb-$(CONFIG_ARCH_MOXART) += moxart-uc7112lx.dtb targets += dtbs targets += $(dtb-y) diff --git a/arch/arm/boot/dts/moxart-uc7112lx.dts b/arch/arm/boot/dts/moxart-uc7112lx.dts new file mode 100644 index 0000000..c63d013 --- /dev/null +++ b/arch/arm/boot/dts/moxart-uc7112lx.dts @@ -0,0 +1,131 @@ +/* moxart-uc7112lx.dts - Device Tree file for MOXA UC-7112-LX + * + * Copyright (C) 2013 Jonas Jensen <jonas.jensen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> + * + * Licensed under GPLv2 or later. + */ + +/dts-v1/; +/include/ "moxart.dtsi" + +/ { + model = "MOXA UC-7112-LX"; + compatible = "moxa,moxart-uc-7112-lx", "moxa,moxart"; + + memory { + device_type = "memory"; + reg = <0x0 0x2000000>; + }; + + flash@80000000,0 { + compatible = "numonyx,js28f128", "cfi-flash"; + reg = <0x80000000 0x1000000>; + bank-width = <2>; + #address-cells = <1>; + #size-cells = <1>; + partition@0 { + label = "bootloader"; + reg = <0x0 0x40000>; + }; + partition@40000 { + label = "linux kernel"; + reg = <0x40000 0x1C0000>; + }; + partition@200000 { + label = "root filesystem"; + reg = <0x200000 0x800000>; + }; + partition@a00000 { + label = "user filesystem"; + reg = <0xa00000 0x600000>; + }; + }; + + sdhci: sdhci@98e00000 { + compatible = "moxa,moxart-sdhci"; + reg = <0x98e00000 0x5C>; + interrupts = <5 0>; + clocks = <&clk_apb>; + dmas = <&dma 5>, + <&dma 5>; + dma-names = "tx", "rx"; + }; + + mdio0: mdio@90900090 { + compatible = "moxa,moxart-mdio"; + reg = <0x90900090 0x8>; + #address-cells = <1>; + #size-cells = <0>; + + ethphy0: ethernet-phy@1 { + device_type = "ethernet-phy"; + compatible = "moxa,moxart-rtl8201cp", "ethernet-phy-ieee802.3-c22"; + reg = <1>; + }; + }; + + mdio1: mdio@92000090 { + compatible = "moxa,moxart-mdio"; + reg = <0x92000090 0x8>; + #address-cells = <1>; + #size-cells = <0>; + + ethphy1: ethernet-phy@1 { + device_type = "ethernet-phy"; + compatible = "moxa,moxart-rtl8201cp", "ethernet-phy-ieee802.3-c22"; + reg = <1>; + }; + }; + + mac0: mac@90900000 { + compatible = "moxa,moxart-mac"; + reg = <0x90900000 0x90>; + interrupts = <25 0>; + phy-handle = <ðphy0>; + phy-mode = "mii"; + }; + + mac1: mac@92000000 { + compatible = "moxa,moxart-mac"; + reg = <0x92000000 0x90>; + interrupts = <27 0>; + phy-handle = <ðphy1>; + phy-mode = "mii"; + }; + + uart0: uart@98200000 { + compatible = "ns16550a"; + reg = <0x98200000 0x20>; + interrupts = <31 8>; + reg-shift = <2>; + reg-io-width = <4>; + clock-frequency = <14745600>; + status = "okay"; + }; + + leds { + compatible = "gpio-leds"; + user-led { + label = "ready-led"; + gpios = <&gpio 27 0x1>; + default-state = "on"; + linux,default-trigger = "default-on"; + }; + }; + + gpio_keys_polled { + compatible = "gpio-keys-polled"; + #address-cells = <1>; + #size-cells = <0>; + poll-interval = <500>; + button@25 { + label = "GPIO Reset"; + linux,code = <116>; + gpios = <&gpio 25 1>; + }; + }; + + chosen { + bootargs = "console=ttyS0,115200n8 earlyprintk root=/dev/mmcblk0p1 rw rootwait"; + }; +}; diff --git a/arch/arm/boot/dts/moxart.dtsi b/arch/arm/boot/dts/moxart.dtsi new file mode 100644 index 0000000..0ea51ed --- /dev/null +++ b/arch/arm/boot/dts/moxart.dtsi @@ -0,0 +1,100 @@ +/* moxart.dtsi - Device Tree Include file for MOXA ART family SoC + * + * Copyright (C) 2013 Jonas Jensen <jonas.jensen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> + * + * Licensed under GPLv2 or later. + */ + +/include/ "skeleton.dtsi" + +/ { + compatible = "moxa,moxart"; + model = "MOXART"; + interrupt-parent = <&intc>; + + cpus { + #address-cells = <1>; + #size-cells = <0>; + + cpu@0 { + device_type = "cpu"; + compatible = "faraday,fa526"; + reg = <0>; + }; + }; + + clocks { + #address-cells = <1>; + #size-cells = <0>; + + ref12: ref12M { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <12000000>; + }; + }; + + soc { + compatible = "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0x90000000 0x10000000>; + ranges; + + intc: interrupt-controller@98800000 { + compatible = "moxa,moxart-ic"; + reg = <0x98800000 0x38>; + interrupt-controller; + #interrupt-cells = <2>; + interrupt-mask = <0x00080000>; + }; + + clk_pll: clk_pll@98100000 { + compatible = "moxa,moxart-pll-clock"; + #clock-cells = <0>; + reg = <0x98100000 0x34>; + clocks = <&ref12>; + }; + + clk_apb: clk_apb@98100000 { + compatible = "moxa,moxart-apb-clock"; + #clock-cells = <0>; + reg = <0x98100000 0x34>; + clocks = <&clk_pll>; + }; + + timer: timer@98400000 { + compatible = "moxa,moxart-timer"; + reg = <0x98400000 0x42>; + interrupts = <19 1>; + clocks = <&clk_apb>; + }; + + gpio: gpio@98700000 { + gpio-controller; + #gpio-cells = <2>; + compatible = "moxa,moxart-gpio"; + reg = <0x98700000 0xC>; + }; + + rtc: rtc { + compatible = "moxa,moxart-rtc"; + gpio-rtc-sclk = <&gpio 5 0>; + gpio-rtc-data = <&gpio 6 0>; + gpio-rtc-reset = <&gpio 7 0>; + }; + + dma: dma@90500000 { + compatible = "moxa,moxart-dma"; + reg = <0x90500080 0x40>; + interrupts = <24 0>; + #dma-cells = <1>; + }; + + watchdog: watchdog@98500000 { + compatible = "moxa,moxart-watchdog"; + reg = <0x98500000 0x10>; + clocks = <&clk_apb>; + }; + }; +}; -- 1.8.2.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply related [flat|nested] 44+ messages in thread
* Re: [PATCH v4 2/2] ARM: mach-moxart: add MOXA ART SoC device tree files 2013-12-13 14:33 ` Jonas Jensen @ 2013-12-13 16:17 ` Arnd Bergmann -1 siblings, 0 replies; 44+ messages in thread From: Arnd Bergmann @ 2013-12-13 16:17 UTC (permalink / raw) To: Jonas Jensen Cc: linux-arm-kernel, linux-kernel, devicetree-discuss, arm, linux, olof On Friday 13 December 2013, Jonas Jensen wrote: > Add a generic (dtsi) include file for MOXA ART SoCs. > > Also add a file for UC-7112-LX. > > Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com> Acked-by: Arnd Bergmann <arnd@arndb.de> ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v4 2/2] ARM: mach-moxart: add MOXA ART SoC device tree files @ 2013-12-13 16:17 ` Arnd Bergmann 0 siblings, 0 replies; 44+ messages in thread From: Arnd Bergmann @ 2013-12-13 16:17 UTC (permalink / raw) To: linux-arm-kernel On Friday 13 December 2013, Jonas Jensen wrote: > Add a generic (dtsi) include file for MOXA ART SoCs. > > Also add a file for UC-7112-LX. > > Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com> Acked-by: Arnd Bergmann <arnd@arndb.de> ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v4 2/2] ARM: mach-moxart: add MOXA ART SoC device tree files 2013-12-13 14:33 ` Jonas Jensen @ 2013-12-15 4:27 ` Peter Crosthwaite -1 siblings, 0 replies; 44+ messages in thread From: Peter Crosthwaite @ 2013-12-15 4:27 UTC (permalink / raw) To: Jonas Jensen Cc: linux-arm-kernel, linux-kernel, devicetree-discuss, arm, linux, Arnd Bergmann, olof On Sat, Dec 14, 2013 at 12:33 AM, Jonas Jensen <jonas.jensen@gmail.com> wrote: > Add a generic (dtsi) include file for MOXA ART SoCs. > > Also add a file for UC-7112-LX. > > Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com> > --- > Documentation/devicetree/bindings/arm/moxart.txt | 12 +++ > arch/arm/boot/dts/Makefile | 1 + > arch/arm/boot/dts/moxart-uc7112lx.dts | 131 +++++++++++++++++++++++ > arch/arm/boot/dts/moxart.dtsi | 100 +++++++++++++++++ > 4 files changed, 244 insertions(+) > create mode 100644 Documentation/devicetree/bindings/arm/moxart.txt > create mode 100644 arch/arm/boot/dts/moxart-uc7112lx.dts > create mode 100644 arch/arm/boot/dts/moxart.dtsi > > diff --git a/Documentation/devicetree/bindings/arm/moxart.txt b/Documentation/devicetree/bindings/arm/moxart.txt > new file mode 100644 > index 0000000..11087ed > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/moxart.txt > @@ -0,0 +1,12 @@ > +MOXA ART device tree bindings > + > +Boards with the MOXA ART SoC shall have the following properties: > + > +Required root node property: > + > +compatible = "moxa,moxart"; > + > +Boards: > + > +- UC-7112-LX: embedded computer > + compatible = "moxa,moxart-uc-7112-lx", "moxa,moxart" > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile > index 9fe33e7..f331b22 100644 > --- a/arch/arm/boot/dts/Makefile > +++ b/arch/arm/boot/dts/Makefile > @@ -318,6 +318,7 @@ dtb-$(CONFIG_ARCH_VT8500) += vt8500-bv07.dtb \ > dtb-$(CONFIG_ARCH_ZYNQ) += zynq-zc702.dtb \ > zynq-zc706.dtb \ > zynq-zed.dtb > +dtb-$(CONFIG_ARCH_MOXART) += moxart-uc7112lx.dtb > > targets += dtbs > targets += $(dtb-y) > diff --git a/arch/arm/boot/dts/moxart-uc7112lx.dts b/arch/arm/boot/dts/moxart-uc7112lx.dts > new file mode 100644 > index 0000000..c63d013 > --- /dev/null > +++ b/arch/arm/boot/dts/moxart-uc7112lx.dts > @@ -0,0 +1,131 @@ > +/* moxart-uc7112lx.dts - Device Tree file for MOXA UC-7112-LX > + * > + * Copyright (C) 2013 Jonas Jensen <jonas.jensen@gmail.com> > + * > + * Licensed under GPLv2 or later. > + */ > + > +/dts-v1/; > +/include/ "moxart.dtsi" > + > +/ { > + model = "MOXA UC-7112-LX"; > + compatible = "moxa,moxart-uc-7112-lx", "moxa,moxart"; > + > + memory { > + device_type = "memory"; > + reg = <0x0 0x2000000>; > + }; > + > + flash@80000000,0 { > + compatible = "numonyx,js28f128", "cfi-flash"; > + reg = <0x80000000 0x1000000>; > + bank-width = <2>; > + #address-cells = <1>; > + #size-cells = <1>; > + partition@0 { > + label = "bootloader"; > + reg = <0x0 0x40000>; > + }; > + partition@40000 { > + label = "linux kernel"; > + reg = <0x40000 0x1C0000>; > + }; > + partition@200000 { > + label = "root filesystem"; > + reg = <0x200000 0x800000>; > + }; > + partition@a00000 { > + label = "user filesystem"; > + reg = <0xa00000 0x600000>; > + }; > + }; > + > + sdhci: sdhci@98e00000 { > + compatible = "moxa,moxart-sdhci"; > + reg = <0x98e00000 0x5C>; > + interrupts = <5 0>; > + clocks = <&clk_apb>; > + dmas = <&dma 5>, > + <&dma 5>; > + dma-names = "tx", "rx"; > + }; Is your SDHCI really implemented on the board level? The fact that its reg property is within the same as the SoC range (for your dtsi) suggests the SDHCI is part of the SoC and should perhaps be in the dtsi? > + > + mdio0: mdio@90900090 { > + compatible = "moxa,moxart-mdio"; > + reg = <0x90900090 0x8>; > + #address-cells = <1>; > + #size-cells = <0>; > + > + ethphy0: ethernet-phy@1 { > + device_type = "ethernet-phy"; > + compatible = "moxa,moxart-rtl8201cp", "ethernet-phy-ieee802.3-c22"; > + reg = <1>; > + }; > + }; > + > + mdio1: mdio@92000090 { > + compatible = "moxa,moxart-mdio"; > + reg = <0x92000090 0x8>; > + #address-cells = <1>; > + #size-cells = <0>; > + > + ethphy1: ethernet-phy@1 { > + device_type = "ethernet-phy"; > + compatible = "moxa,moxart-rtl8201cp", "ethernet-phy-ieee802.3-c22"; > + reg = <1>; > + }; > + }; > + > + mac0: mac@90900000 { > + compatible = "moxa,moxart-mac"; > + reg = <0x90900000 0x90>; > + interrupts = <25 0>; > + phy-handle = <ðphy0>; > + phy-mode = "mii"; > + }; > + > + mac1: mac@92000000 { > + compatible = "moxa,moxart-mac"; > + reg = <0x92000000 0x90>; > + interrupts = <27 0>; > + phy-handle = <ðphy1>; > + phy-mode = "mii"; > + }; Same for MACs. > + > + uart0: uart@98200000 { > + compatible = "ns16550a"; > + reg = <0x98200000 0x20>; > + interrupts = <31 8>; > + reg-shift = <2>; > + reg-io-width = <4>; > + clock-frequency = <14745600>; > + status = "okay"; > + }; > + And UARTs. Let me know if i'm misunderstanding dts/dtsi split but looking at some of the other SoCs this seems inconsistent to me. Regards, Peter > + leds { > + compatible = "gpio-leds"; > + user-led { > + label = "ready-led"; > + gpios = <&gpio 27 0x1>; > + default-state = "on"; > + linux,default-trigger = "default-on"; > + }; > + }; > + > + gpio_keys_polled { > + compatible = "gpio-keys-polled"; > + #address-cells = <1>; > + #size-cells = <0>; > + poll-interval = <500>; > + button@25 { > + label = "GPIO Reset"; > + linux,code = <116>; > + gpios = <&gpio 25 1>; > + }; > + }; > + > + chosen { > + bootargs = "console=ttyS0,115200n8 earlyprintk root=/dev/mmcblk0p1 rw rootwait"; > + }; > +}; > diff --git a/arch/arm/boot/dts/moxart.dtsi b/arch/arm/boot/dts/moxart.dtsi > new file mode 100644 > index 0000000..0ea51ed > --- /dev/null > +++ b/arch/arm/boot/dts/moxart.dtsi > @@ -0,0 +1,100 @@ > +/* moxart.dtsi - Device Tree Include file for MOXA ART family SoC > + * > + * Copyright (C) 2013 Jonas Jensen <jonas.jensen@gmail.com> > + * > + * Licensed under GPLv2 or later. > + */ > + > +/include/ "skeleton.dtsi" > + > +/ { > + compatible = "moxa,moxart"; > + model = "MOXART"; > + interrupt-parent = <&intc>; > + > + cpus { > + #address-cells = <1>; > + #size-cells = <0>; > + > + cpu@0 { > + device_type = "cpu"; > + compatible = "faraday,fa526"; > + reg = <0>; > + }; > + }; > + > + clocks { > + #address-cells = <1>; > + #size-cells = <0>; > + > + ref12: ref12M { > + compatible = "fixed-clock"; > + #clock-cells = <0>; > + clock-frequency = <12000000>; > + }; > + }; > + > + soc { > + compatible = "simple-bus"; > + #address-cells = <1>; > + #size-cells = <1>; > + reg = <0x90000000 0x10000000>; > + ranges; > + > + intc: interrupt-controller@98800000 { > + compatible = "moxa,moxart-ic"; > + reg = <0x98800000 0x38>; > + interrupt-controller; > + #interrupt-cells = <2>; > + interrupt-mask = <0x00080000>; > + }; > + > + clk_pll: clk_pll@98100000 { > + compatible = "moxa,moxart-pll-clock"; > + #clock-cells = <0>; > + reg = <0x98100000 0x34>; > + clocks = <&ref12>; > + }; > + > + clk_apb: clk_apb@98100000 { > + compatible = "moxa,moxart-apb-clock"; > + #clock-cells = <0>; > + reg = <0x98100000 0x34>; > + clocks = <&clk_pll>; > + }; > + > + timer: timer@98400000 { > + compatible = "moxa,moxart-timer"; > + reg = <0x98400000 0x42>; > + interrupts = <19 1>; > + clocks = <&clk_apb>; > + }; > + > + gpio: gpio@98700000 { > + gpio-controller; > + #gpio-cells = <2>; > + compatible = "moxa,moxart-gpio"; > + reg = <0x98700000 0xC>; > + }; > + > + rtc: rtc { > + compatible = "moxa,moxart-rtc"; > + gpio-rtc-sclk = <&gpio 5 0>; > + gpio-rtc-data = <&gpio 6 0>; > + gpio-rtc-reset = <&gpio 7 0>; > + }; > + > + dma: dma@90500000 { > + compatible = "moxa,moxart-dma"; > + reg = <0x90500080 0x40>; > + interrupts = <24 0>; > + #dma-cells = <1>; > + }; > + > + watchdog: watchdog@98500000 { > + compatible = "moxa,moxart-watchdog"; > + reg = <0x98500000 0x10>; > + clocks = <&clk_apb>; > + }; > + }; > +}; > -- > 1.8.2.1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v4 2/2] ARM: mach-moxart: add MOXA ART SoC device tree files @ 2013-12-15 4:27 ` Peter Crosthwaite 0 siblings, 0 replies; 44+ messages in thread From: Peter Crosthwaite @ 2013-12-15 4:27 UTC (permalink / raw) To: linux-arm-kernel On Sat, Dec 14, 2013 at 12:33 AM, Jonas Jensen <jonas.jensen@gmail.com> wrote: > Add a generic (dtsi) include file for MOXA ART SoCs. > > Also add a file for UC-7112-LX. > > Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com> > --- > Documentation/devicetree/bindings/arm/moxart.txt | 12 +++ > arch/arm/boot/dts/Makefile | 1 + > arch/arm/boot/dts/moxart-uc7112lx.dts | 131 +++++++++++++++++++++++ > arch/arm/boot/dts/moxart.dtsi | 100 +++++++++++++++++ > 4 files changed, 244 insertions(+) > create mode 100644 Documentation/devicetree/bindings/arm/moxart.txt > create mode 100644 arch/arm/boot/dts/moxart-uc7112lx.dts > create mode 100644 arch/arm/boot/dts/moxart.dtsi > > diff --git a/Documentation/devicetree/bindings/arm/moxart.txt b/Documentation/devicetree/bindings/arm/moxart.txt > new file mode 100644 > index 0000000..11087ed > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/moxart.txt > @@ -0,0 +1,12 @@ > +MOXA ART device tree bindings > + > +Boards with the MOXA ART SoC shall have the following properties: > + > +Required root node property: > + > +compatible = "moxa,moxart"; > + > +Boards: > + > +- UC-7112-LX: embedded computer > + compatible = "moxa,moxart-uc-7112-lx", "moxa,moxart" > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile > index 9fe33e7..f331b22 100644 > --- a/arch/arm/boot/dts/Makefile > +++ b/arch/arm/boot/dts/Makefile > @@ -318,6 +318,7 @@ dtb-$(CONFIG_ARCH_VT8500) += vt8500-bv07.dtb \ > dtb-$(CONFIG_ARCH_ZYNQ) += zynq-zc702.dtb \ > zynq-zc706.dtb \ > zynq-zed.dtb > +dtb-$(CONFIG_ARCH_MOXART) += moxart-uc7112lx.dtb > > targets += dtbs > targets += $(dtb-y) > diff --git a/arch/arm/boot/dts/moxart-uc7112lx.dts b/arch/arm/boot/dts/moxart-uc7112lx.dts > new file mode 100644 > index 0000000..c63d013 > --- /dev/null > +++ b/arch/arm/boot/dts/moxart-uc7112lx.dts > @@ -0,0 +1,131 @@ > +/* moxart-uc7112lx.dts - Device Tree file for MOXA UC-7112-LX > + * > + * Copyright (C) 2013 Jonas Jensen <jonas.jensen@gmail.com> > + * > + * Licensed under GPLv2 or later. > + */ > + > +/dts-v1/; > +/include/ "moxart.dtsi" > + > +/ { > + model = "MOXA UC-7112-LX"; > + compatible = "moxa,moxart-uc-7112-lx", "moxa,moxart"; > + > + memory { > + device_type = "memory"; > + reg = <0x0 0x2000000>; > + }; > + > + flash at 80000000,0 { > + compatible = "numonyx,js28f128", "cfi-flash"; > + reg = <0x80000000 0x1000000>; > + bank-width = <2>; > + #address-cells = <1>; > + #size-cells = <1>; > + partition at 0 { > + label = "bootloader"; > + reg = <0x0 0x40000>; > + }; > + partition at 40000 { > + label = "linux kernel"; > + reg = <0x40000 0x1C0000>; > + }; > + partition at 200000 { > + label = "root filesystem"; > + reg = <0x200000 0x800000>; > + }; > + partition at a00000 { > + label = "user filesystem"; > + reg = <0xa00000 0x600000>; > + }; > + }; > + > + sdhci: sdhci at 98e00000 { > + compatible = "moxa,moxart-sdhci"; > + reg = <0x98e00000 0x5C>; > + interrupts = <5 0>; > + clocks = <&clk_apb>; > + dmas = <&dma 5>, > + <&dma 5>; > + dma-names = "tx", "rx"; > + }; Is your SDHCI really implemented on the board level? The fact that its reg property is within the same as the SoC range (for your dtsi) suggests the SDHCI is part of the SoC and should perhaps be in the dtsi? > + > + mdio0: mdio at 90900090 { > + compatible = "moxa,moxart-mdio"; > + reg = <0x90900090 0x8>; > + #address-cells = <1>; > + #size-cells = <0>; > + > + ethphy0: ethernet-phy at 1 { > + device_type = "ethernet-phy"; > + compatible = "moxa,moxart-rtl8201cp", "ethernet-phy-ieee802.3-c22"; > + reg = <1>; > + }; > + }; > + > + mdio1: mdio at 92000090 { > + compatible = "moxa,moxart-mdio"; > + reg = <0x92000090 0x8>; > + #address-cells = <1>; > + #size-cells = <0>; > + > + ethphy1: ethernet-phy at 1 { > + device_type = "ethernet-phy"; > + compatible = "moxa,moxart-rtl8201cp", "ethernet-phy-ieee802.3-c22"; > + reg = <1>; > + }; > + }; > + > + mac0: mac at 90900000 { > + compatible = "moxa,moxart-mac"; > + reg = <0x90900000 0x90>; > + interrupts = <25 0>; > + phy-handle = <ðphy0>; > + phy-mode = "mii"; > + }; > + > + mac1: mac at 92000000 { > + compatible = "moxa,moxart-mac"; > + reg = <0x92000000 0x90>; > + interrupts = <27 0>; > + phy-handle = <ðphy1>; > + phy-mode = "mii"; > + }; Same for MACs. > + > + uart0: uart at 98200000 { > + compatible = "ns16550a"; > + reg = <0x98200000 0x20>; > + interrupts = <31 8>; > + reg-shift = <2>; > + reg-io-width = <4>; > + clock-frequency = <14745600>; > + status = "okay"; > + }; > + And UARTs. Let me know if i'm misunderstanding dts/dtsi split but looking at some of the other SoCs this seems inconsistent to me. Regards, Peter > + leds { > + compatible = "gpio-leds"; > + user-led { > + label = "ready-led"; > + gpios = <&gpio 27 0x1>; > + default-state = "on"; > + linux,default-trigger = "default-on"; > + }; > + }; > + > + gpio_keys_polled { > + compatible = "gpio-keys-polled"; > + #address-cells = <1>; > + #size-cells = <0>; > + poll-interval = <500>; > + button at 25 { > + label = "GPIO Reset"; > + linux,code = <116>; > + gpios = <&gpio 25 1>; > + }; > + }; > + > + chosen { > + bootargs = "console=ttyS0,115200n8 earlyprintk root=/dev/mmcblk0p1 rw rootwait"; > + }; > +}; > diff --git a/arch/arm/boot/dts/moxart.dtsi b/arch/arm/boot/dts/moxart.dtsi > new file mode 100644 > index 0000000..0ea51ed > --- /dev/null > +++ b/arch/arm/boot/dts/moxart.dtsi > @@ -0,0 +1,100 @@ > +/* moxart.dtsi - Device Tree Include file for MOXA ART family SoC > + * > + * Copyright (C) 2013 Jonas Jensen <jonas.jensen@gmail.com> > + * > + * Licensed under GPLv2 or later. > + */ > + > +/include/ "skeleton.dtsi" > + > +/ { > + compatible = "moxa,moxart"; > + model = "MOXART"; > + interrupt-parent = <&intc>; > + > + cpus { > + #address-cells = <1>; > + #size-cells = <0>; > + > + cpu at 0 { > + device_type = "cpu"; > + compatible = "faraday,fa526"; > + reg = <0>; > + }; > + }; > + > + clocks { > + #address-cells = <1>; > + #size-cells = <0>; > + > + ref12: ref12M { > + compatible = "fixed-clock"; > + #clock-cells = <0>; > + clock-frequency = <12000000>; > + }; > + }; > + > + soc { > + compatible = "simple-bus"; > + #address-cells = <1>; > + #size-cells = <1>; > + reg = <0x90000000 0x10000000>; > + ranges; > + > + intc: interrupt-controller at 98800000 { > + compatible = "moxa,moxart-ic"; > + reg = <0x98800000 0x38>; > + interrupt-controller; > + #interrupt-cells = <2>; > + interrupt-mask = <0x00080000>; > + }; > + > + clk_pll: clk_pll at 98100000 { > + compatible = "moxa,moxart-pll-clock"; > + #clock-cells = <0>; > + reg = <0x98100000 0x34>; > + clocks = <&ref12>; > + }; > + > + clk_apb: clk_apb at 98100000 { > + compatible = "moxa,moxart-apb-clock"; > + #clock-cells = <0>; > + reg = <0x98100000 0x34>; > + clocks = <&clk_pll>; > + }; > + > + timer: timer at 98400000 { > + compatible = "moxa,moxart-timer"; > + reg = <0x98400000 0x42>; > + interrupts = <19 1>; > + clocks = <&clk_apb>; > + }; > + > + gpio: gpio at 98700000 { > + gpio-controller; > + #gpio-cells = <2>; > + compatible = "moxa,moxart-gpio"; > + reg = <0x98700000 0xC>; > + }; > + > + rtc: rtc { > + compatible = "moxa,moxart-rtc"; > + gpio-rtc-sclk = <&gpio 5 0>; > + gpio-rtc-data = <&gpio 6 0>; > + gpio-rtc-reset = <&gpio 7 0>; > + }; > + > + dma: dma at 90500000 { > + compatible = "moxa,moxart-dma"; > + reg = <0x90500080 0x40>; > + interrupts = <24 0>; > + #dma-cells = <1>; > + }; > + > + watchdog: watchdog at 98500000 { > + compatible = "moxa,moxart-watchdog"; > + reg = <0x98500000 0x10>; > + clocks = <&clk_apb>; > + }; > + }; > +}; > -- > 1.8.2.1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v4 2/2] ARM: mach-moxart: add MOXA ART SoC device tree files 2013-12-15 4:27 ` Peter Crosthwaite @ 2013-12-16 20:05 ` Jonas Jensen -1 siblings, 0 replies; 44+ messages in thread From: Jonas Jensen @ 2013-12-16 20:05 UTC (permalink / raw) To: Peter Crosthwaite Cc: linux-arm-kernel, linux-kernel, devicetree-discuss, arm, Russell King - ARM Linux, Arnd Bergmann, Olof Johansson On 15 December 2013 05:27, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote: >> + sdhci: sdhci@98e00000 { >> + compatible = "moxa,moxart-sdhci"; >> + reg = <0x98e00000 0x5C>; >> + interrupts = <5 0>; >> + clocks = <&clk_apb>; >> + dmas = <&dma 5>, >> + <&dma 5>; >> + dma-names = "tx", "rx"; >> + }; > > Is your SDHCI really implemented on the board level? The fact that its > reg property is within the same as the SoC range (for your dtsi) > suggests the SDHCI is part of the SoC and should perhaps be in the > dtsi? >> + mac1: mac@92000000 { >> + compatible = "moxa,moxart-mac"; >> + reg = <0x92000000 0x90>; >> + interrupts = <27 0>; >> + phy-handle = <ðphy1>; >> + phy-mode = "mii"; >> + }; > > Same for MACs. >> + >> + uart0: uart@98200000 { >> + compatible = "ns16550a"; >> + reg = <0x98200000 0x20>; >> + interrupts = <31 8>; >> + reg-shift = <2>; >> + reg-io-width = <4>; >> + clock-frequency = <14745600>; >> + status = "okay"; >> + }; >> + > > And UARTs. > > Let me know if i'm misunderstanding dts/dtsi split but looking at some > of the other SoCs this seems inconsistent to me. It is likely to be true, that technically these are all part of the SoC. By examining the hardware, there are no external chips (on either base or main board) that looks capable of handling such functions: https://plus.google.com/photos/103371465418643926605/albums/5820634595801767953 I made the split with some consideration to other MOXA ART machines, that they can be added as a separate file including the same dtsi: MOXA ART hardware examples: UC-7112/UC-7110: "SD slot (UC-7112, and UC-7112 Plus only)": http://www.moxa.com/product/UC-7112_UC-7110.htm IA241: "64 MB RAM": http://www.moxa.com/product/IA241_IA240.htm UC-7101-LX: "One 10/100 Mbps Ethernet port": http://www.moxa.com/product/UC-7101-LX.htm UC-7112-LX has 32 MB RAM and two ethernet ports. This is why I think MAC is good as is, RAM should move out from SoC? I don't know if they all have a debug UART (I only have access to UC-7112-LX), and it's not obvious in specifications. UART can possibly be moved into SoC as you say. In cases where SD slot is missing but the register remains in the SoC, how is that normally handled? Regards, Jonas ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v4 2/2] ARM: mach-moxart: add MOXA ART SoC device tree files @ 2013-12-16 20:05 ` Jonas Jensen 0 siblings, 0 replies; 44+ messages in thread From: Jonas Jensen @ 2013-12-16 20:05 UTC (permalink / raw) To: linux-arm-kernel On 15 December 2013 05:27, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote: >> + sdhci: sdhci at 98e00000 { >> + compatible = "moxa,moxart-sdhci"; >> + reg = <0x98e00000 0x5C>; >> + interrupts = <5 0>; >> + clocks = <&clk_apb>; >> + dmas = <&dma 5>, >> + <&dma 5>; >> + dma-names = "tx", "rx"; >> + }; > > Is your SDHCI really implemented on the board level? The fact that its > reg property is within the same as the SoC range (for your dtsi) > suggests the SDHCI is part of the SoC and should perhaps be in the > dtsi? >> + mac1: mac at 92000000 { >> + compatible = "moxa,moxart-mac"; >> + reg = <0x92000000 0x90>; >> + interrupts = <27 0>; >> + phy-handle = <ðphy1>; >> + phy-mode = "mii"; >> + }; > > Same for MACs. >> + >> + uart0: uart at 98200000 { >> + compatible = "ns16550a"; >> + reg = <0x98200000 0x20>; >> + interrupts = <31 8>; >> + reg-shift = <2>; >> + reg-io-width = <4>; >> + clock-frequency = <14745600>; >> + status = "okay"; >> + }; >> + > > And UARTs. > > Let me know if i'm misunderstanding dts/dtsi split but looking at some > of the other SoCs this seems inconsistent to me. It is likely to be true, that technically these are all part of the SoC. By examining the hardware, there are no external chips (on either base or main board) that looks capable of handling such functions: https://plus.google.com/photos/103371465418643926605/albums/5820634595801767953 I made the split with some consideration to other MOXA ART machines, that they can be added as a separate file including the same dtsi: MOXA ART hardware examples: UC-7112/UC-7110: "SD slot (UC-7112, and UC-7112 Plus only)": http://www.moxa.com/product/UC-7112_UC-7110.htm IA241: "64 MB RAM": http://www.moxa.com/product/IA241_IA240.htm UC-7101-LX: "One 10/100 Mbps Ethernet port": http://www.moxa.com/product/UC-7101-LX.htm UC-7112-LX has 32 MB RAM and two ethernet ports. This is why I think MAC is good as is, RAM should move out from SoC? I don't know if they all have a debug UART (I only have access to UC-7112-LX), and it's not obvious in specifications. UART can possibly be moved into SoC as you say. In cases where SD slot is missing but the register remains in the SoC, how is that normally handled? Regards, Jonas ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v4 2/2] ARM: mach-moxart: add MOXA ART SoC device tree files 2013-12-16 20:05 ` Jonas Jensen (?) @ 2013-12-16 23:53 ` Peter Crosthwaite -1 siblings, 0 replies; 44+ messages in thread From: Peter Crosthwaite @ 2013-12-16 23:53 UTC (permalink / raw) To: Jonas Jensen Cc: linux-arm-kernel, linux-kernel, devicetree-discuss, arm, Russell King - ARM Linux, Arnd Bergmann, Olof Johansson, devicetree, Soren Brinkmann On Tue, Dec 17, 2013 at 6:05 AM, Jonas Jensen <jonas.jensen@gmail.com> wrote: > On 15 December 2013 05:27, Peter Crosthwaite > <peter.crosthwaite@xilinx.com> wrote: >>> + sdhci: sdhci@98e00000 { >>> + compatible = "moxa,moxart-sdhci"; >>> + reg = <0x98e00000 0x5C>; >>> + interrupts = <5 0>; >>> + clocks = <&clk_apb>; >>> + dmas = <&dma 5>, >>> + <&dma 5>; >>> + dma-names = "tx", "rx"; >>> + }; >> >> Is your SDHCI really implemented on the board level? The fact that its >> reg property is within the same as the SoC range (for your dtsi) >> suggests the SDHCI is part of the SoC and should perhaps be in the >> dtsi? > >>> + mac1: mac@92000000 { >>> + compatible = "moxa,moxart-mac"; >>> + reg = <0x92000000 0x90>; >>> + interrupts = <27 0>; >>> + phy-handle = <ðphy1>; >>> + phy-mode = "mii"; >>> + }; >> >> Same for MACs. > >>> + >>> + uart0: uart@98200000 { >>> + compatible = "ns16550a"; >>> + reg = <0x98200000 0x20>; >>> + interrupts = <31 8>; >>> + reg-shift = <2>; >>> + reg-io-width = <4>; >>> + clock-frequency = <14745600>; >>> + status = "okay"; >>> + }; >>> + >> >> And UARTs. >> >> Let me know if i'm misunderstanding dts/dtsi split but looking at some >> of the other SoCs this seems inconsistent to me. > > > It is likely to be true, that technically these are all part of the > SoC. By examining the hardware, there are no external chips (on either > base or main board) that looks capable of handling such functions: > > https://plus.google.com/photos/103371465418643926605/albums/5820634595801767953 > > I made the split with some consideration to other MOXA ART machines, > that they can be added as a separate file including the same dtsi: > > MOXA ART hardware examples: > > UC-7112/UC-7110: "SD slot (UC-7112, and UC-7112 Plus only)": > http://www.moxa.com/product/UC-7112_UC-7110.htm > > IA241: "64 MB RAM": > http://www.moxa.com/product/IA241_IA240.htm > > UC-7101-LX: "One 10/100 Mbps Ethernet port": > http://www.moxa.com/product/UC-7101-LX.htm > > > UC-7112-LX has 32 MB RAM and two ethernet ports. This is why I think > MAC is good as is, RAM should move out from SoC? > > I don't know if they all have a debug UART (I only have access to > UC-7112-LX), and it's not obvious in specifications. UART can possibly > be moved into SoC as you say. > I think its going to all be in the SoC. Having it board level would mean you have a system bus as copper which is not very SoC like (at least for UART anyway). > In cases where SD slot is missing but the register remains in the SoC, > how is that normally handled? > Soren Brinkmann's recent addition of ethernet to the Zynq SoC illustrates the concept for a MAC. The two MACs are added to the shared dtsi but disabled. The board level dts then enables it for the one which is board populated: https://lkml.org/lkml/2013/12/11/434 I think its generally applicable to your SD MAC and UART cases. The tegra20 dtsi illustrates the status = "disabled" concept specifically for SDHCI. Regards, Peter > > Regards, > Jonas > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v4 2/2] ARM: mach-moxart: add MOXA ART SoC device tree files @ 2013-12-16 23:53 ` Peter Crosthwaite 0 siblings, 0 replies; 44+ messages in thread From: Peter Crosthwaite @ 2013-12-16 23:53 UTC (permalink / raw) To: linux-arm-kernel On Tue, Dec 17, 2013 at 6:05 AM, Jonas Jensen <jonas.jensen@gmail.com> wrote: > On 15 December 2013 05:27, Peter Crosthwaite > <peter.crosthwaite@xilinx.com> wrote: >>> + sdhci: sdhci at 98e00000 { >>> + compatible = "moxa,moxart-sdhci"; >>> + reg = <0x98e00000 0x5C>; >>> + interrupts = <5 0>; >>> + clocks = <&clk_apb>; >>> + dmas = <&dma 5>, >>> + <&dma 5>; >>> + dma-names = "tx", "rx"; >>> + }; >> >> Is your SDHCI really implemented on the board level? The fact that its >> reg property is within the same as the SoC range (for your dtsi) >> suggests the SDHCI is part of the SoC and should perhaps be in the >> dtsi? > >>> + mac1: mac at 92000000 { >>> + compatible = "moxa,moxart-mac"; >>> + reg = <0x92000000 0x90>; >>> + interrupts = <27 0>; >>> + phy-handle = <ðphy1>; >>> + phy-mode = "mii"; >>> + }; >> >> Same for MACs. > >>> + >>> + uart0: uart at 98200000 { >>> + compatible = "ns16550a"; >>> + reg = <0x98200000 0x20>; >>> + interrupts = <31 8>; >>> + reg-shift = <2>; >>> + reg-io-width = <4>; >>> + clock-frequency = <14745600>; >>> + status = "okay"; >>> + }; >>> + >> >> And UARTs. >> >> Let me know if i'm misunderstanding dts/dtsi split but looking at some >> of the other SoCs this seems inconsistent to me. > > > It is likely to be true, that technically these are all part of the > SoC. By examining the hardware, there are no external chips (on either > base or main board) that looks capable of handling such functions: > > https://plus.google.com/photos/103371465418643926605/albums/5820634595801767953 > > I made the split with some consideration to other MOXA ART machines, > that they can be added as a separate file including the same dtsi: > > MOXA ART hardware examples: > > UC-7112/UC-7110: "SD slot (UC-7112, and UC-7112 Plus only)": > http://www.moxa.com/product/UC-7112_UC-7110.htm > > IA241: "64 MB RAM": > http://www.moxa.com/product/IA241_IA240.htm > > UC-7101-LX: "One 10/100 Mbps Ethernet port": > http://www.moxa.com/product/UC-7101-LX.htm > > > UC-7112-LX has 32 MB RAM and two ethernet ports. This is why I think > MAC is good as is, RAM should move out from SoC? > > I don't know if they all have a debug UART (I only have access to > UC-7112-LX), and it's not obvious in specifications. UART can possibly > be moved into SoC as you say. > I think its going to all be in the SoC. Having it board level would mean you have a system bus as copper which is not very SoC like (at least for UART anyway). > In cases where SD slot is missing but the register remains in the SoC, > how is that normally handled? > Soren Brinkmann's recent addition of ethernet to the Zynq SoC illustrates the concept for a MAC. The two MACs are added to the shared dtsi but disabled. The board level dts then enables it for the one which is board populated: https://lkml.org/lkml/2013/12/11/434 I think its generally applicable to your SD MAC and UART cases. The tegra20 dtsi illustrates the status = "disabled" concept specifically for SDHCI. Regards, Peter > > Regards, > Jonas > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v4 2/2] ARM: mach-moxart: add MOXA ART SoC device tree files @ 2013-12-16 23:53 ` Peter Crosthwaite 0 siblings, 0 replies; 44+ messages in thread From: Peter Crosthwaite @ 2013-12-16 23:53 UTC (permalink / raw) To: Jonas Jensen Cc: linux-arm-kernel, linux-kernel, devicetree-discuss, arm, Russell King - ARM Linux, Arnd Bergmann, Olof Johansson, devicetree, Soren Brinkmann On Tue, Dec 17, 2013 at 6:05 AM, Jonas Jensen <jonas.jensen@gmail.com> wrote: > On 15 December 2013 05:27, Peter Crosthwaite > <peter.crosthwaite@xilinx.com> wrote: >>> + sdhci: sdhci@98e00000 { >>> + compatible = "moxa,moxart-sdhci"; >>> + reg = <0x98e00000 0x5C>; >>> + interrupts = <5 0>; >>> + clocks = <&clk_apb>; >>> + dmas = <&dma 5>, >>> + <&dma 5>; >>> + dma-names = "tx", "rx"; >>> + }; >> >> Is your SDHCI really implemented on the board level? The fact that its >> reg property is within the same as the SoC range (for your dtsi) >> suggests the SDHCI is part of the SoC and should perhaps be in the >> dtsi? > >>> + mac1: mac@92000000 { >>> + compatible = "moxa,moxart-mac"; >>> + reg = <0x92000000 0x90>; >>> + interrupts = <27 0>; >>> + phy-handle = <ðphy1>; >>> + phy-mode = "mii"; >>> + }; >> >> Same for MACs. > >>> + >>> + uart0: uart@98200000 { >>> + compatible = "ns16550a"; >>> + reg = <0x98200000 0x20>; >>> + interrupts = <31 8>; >>> + reg-shift = <2>; >>> + reg-io-width = <4>; >>> + clock-frequency = <14745600>; >>> + status = "okay"; >>> + }; >>> + >> >> And UARTs. >> >> Let me know if i'm misunderstanding dts/dtsi split but looking at some >> of the other SoCs this seems inconsistent to me. > > > It is likely to be true, that technically these are all part of the > SoC. By examining the hardware, there are no external chips (on either > base or main board) that looks capable of handling such functions: > > https://plus.google.com/photos/103371465418643926605/albums/5820634595801767953 > > I made the split with some consideration to other MOXA ART machines, > that they can be added as a separate file including the same dtsi: > > MOXA ART hardware examples: > > UC-7112/UC-7110: "SD slot (UC-7112, and UC-7112 Plus only)": > http://www.moxa.com/product/UC-7112_UC-7110.htm > > IA241: "64 MB RAM": > http://www.moxa.com/product/IA241_IA240.htm > > UC-7101-LX: "One 10/100 Mbps Ethernet port": > http://www.moxa.com/product/UC-7101-LX.htm > > > UC-7112-LX has 32 MB RAM and two ethernet ports. This is why I think > MAC is good as is, RAM should move out from SoC? > > I don't know if they all have a debug UART (I only have access to > UC-7112-LX), and it's not obvious in specifications. UART can possibly > be moved into SoC as you say. > I think its going to all be in the SoC. Having it board level would mean you have a system bus as copper which is not very SoC like (at least for UART anyway). > In cases where SD slot is missing but the register remains in the SoC, > how is that normally handled? > Soren Brinkmann's recent addition of ethernet to the Zynq SoC illustrates the concept for a MAC. The two MACs are added to the shared dtsi but disabled. The board level dts then enables it for the one which is board populated: https://lkml.org/lkml/2013/12/11/434 I think its generally applicable to your SD MAC and UART cases. The tegra20 dtsi illustrates the status = "disabled" concept specifically for SDHCI. Regards, Peter > > Regards, > Jonas > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v4 2/2] ARM: mach-moxart: add MOXA ART SoC device tree files 2013-12-16 23:53 ` Peter Crosthwaite (?) @ 2013-12-17 0:09 ` Sören Brinkmann -1 siblings, 0 replies; 44+ messages in thread From: Sören Brinkmann @ 2013-12-17 0:09 UTC (permalink / raw) To: Peter Crosthwaite Cc: Jonas Jensen, linux-arm-kernel, linux-kernel, devicetree-discuss, arm, Russell King - ARM Linux, Arnd Bergmann, Olof Johansson, devicetree Hi, On Tue, Dec 17, 2013 at 09:53:27AM +1000, Peter Crosthwaite wrote: > On Tue, Dec 17, 2013 at 6:05 AM, Jonas Jensen <jonas.jensen@gmail.com> wrote: > > On 15 December 2013 05:27, Peter Crosthwaite > > <peter.crosthwaite@xilinx.com> wrote: > >>> + sdhci: sdhci@98e00000 { > >>> + compatible = "moxa,moxart-sdhci"; > >>> + reg = <0x98e00000 0x5C>; > >>> + interrupts = <5 0>; > >>> + clocks = <&clk_apb>; > >>> + dmas = <&dma 5>, > >>> + <&dma 5>; > >>> + dma-names = "tx", "rx"; > >>> + }; > >> > >> Is your SDHCI really implemented on the board level? The fact that its > >> reg property is within the same as the SoC range (for your dtsi) > >> suggests the SDHCI is part of the SoC and should perhaps be in the > >> dtsi? > > > >>> + mac1: mac@92000000 { > >>> + compatible = "moxa,moxart-mac"; > >>> + reg = <0x92000000 0x90>; > >>> + interrupts = <27 0>; > >>> + phy-handle = <ðphy1>; > >>> + phy-mode = "mii"; > >>> + }; > >> > >> Same for MACs. > > > >>> + > >>> + uart0: uart@98200000 { > >>> + compatible = "ns16550a"; > >>> + reg = <0x98200000 0x20>; > >>> + interrupts = <31 8>; > >>> + reg-shift = <2>; > >>> + reg-io-width = <4>; > >>> + clock-frequency = <14745600>; > >>> + status = "okay"; > >>> + }; > >>> + > >> > >> And UARTs. > >> > >> Let me know if i'm misunderstanding dts/dtsi split but looking at some > >> of the other SoCs this seems inconsistent to me. > > > > > > It is likely to be true, that technically these are all part of the > > SoC. By examining the hardware, there are no external chips (on either > > base or main board) that looks capable of handling such functions: > > > > https://plus.google.com/photos/103371465418643926605/albums/5820634595801767953 > > > > I made the split with some consideration to other MOXA ART machines, > > that they can be added as a separate file including the same dtsi: > > > > MOXA ART hardware examples: > > > > UC-7112/UC-7110: "SD slot (UC-7112, and UC-7112 Plus only)": > > http://www.moxa.com/product/UC-7112_UC-7110.htm > > > > IA241: "64 MB RAM": > > http://www.moxa.com/product/IA241_IA240.htm > > > > UC-7101-LX: "One 10/100 Mbps Ethernet port": > > http://www.moxa.com/product/UC-7101-LX.htm > > > > > > UC-7112-LX has 32 MB RAM and two ethernet ports. This is why I think > > MAC is good as is, RAM should move out from SoC? > > > > I don't know if they all have a debug UART (I only have access to > > UC-7112-LX), and it's not obvious in specifications. UART can possibly > > be moved into SoC as you say. > > > > I think its going to all be in the SoC. Having it board level would > mean you have a system bus as copper which is not very SoC like (at > least for UART anyway). > > > In cases where SD slot is missing but the register remains in the SoC, > > how is that normally handled? > > > > Soren Brinkmann's recent addition of ethernet to the Zynq SoC > illustrates the concept for a MAC. The two MACs are added to the > shared dtsi but disabled. The board level dts then enables it for the > one which is board populated: > > https://lkml.org/lkml/2013/12/11/434 > > I think its generally applicable to your SD MAC and UART cases. The > tegra20 dtsi illustrates the status = "disabled" concept specifically > for SDHCI. I think it's less SoC vs. non-SoC parts. There are even platforms using more than two levels of includes. IMHO, it's just to avoid duplication. So, stuff that doesn't change ever goes into the lowest level dtsi and then you work your way up. That way people bringing up a board with your part just have to enable the correct set of peripherals and provide board specific properties. You don't want everybody to repeat the same memory map (reg properties), clock references, etc. over and over again in all dtses that use a specific SoC, right? Long story short: I separate by: Properties that are statically defined by the SOC => dtsi. Properties that are defined by the PCB design => board level dts. Sören ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v4 2/2] ARM: mach-moxart: add MOXA ART SoC device tree files @ 2013-12-17 0:09 ` Sören Brinkmann 0 siblings, 0 replies; 44+ messages in thread From: Sören Brinkmann @ 2013-12-17 0:09 UTC (permalink / raw) To: linux-arm-kernel Hi, On Tue, Dec 17, 2013 at 09:53:27AM +1000, Peter Crosthwaite wrote: > On Tue, Dec 17, 2013 at 6:05 AM, Jonas Jensen <jonas.jensen@gmail.com> wrote: > > On 15 December 2013 05:27, Peter Crosthwaite > > <peter.crosthwaite@xilinx.com> wrote: > >>> + sdhci: sdhci at 98e00000 { > >>> + compatible = "moxa,moxart-sdhci"; > >>> + reg = <0x98e00000 0x5C>; > >>> + interrupts = <5 0>; > >>> + clocks = <&clk_apb>; > >>> + dmas = <&dma 5>, > >>> + <&dma 5>; > >>> + dma-names = "tx", "rx"; > >>> + }; > >> > >> Is your SDHCI really implemented on the board level? The fact that its > >> reg property is within the same as the SoC range (for your dtsi) > >> suggests the SDHCI is part of the SoC and should perhaps be in the > >> dtsi? > > > >>> + mac1: mac at 92000000 { > >>> + compatible = "moxa,moxart-mac"; > >>> + reg = <0x92000000 0x90>; > >>> + interrupts = <27 0>; > >>> + phy-handle = <ðphy1>; > >>> + phy-mode = "mii"; > >>> + }; > >> > >> Same for MACs. > > > >>> + > >>> + uart0: uart at 98200000 { > >>> + compatible = "ns16550a"; > >>> + reg = <0x98200000 0x20>; > >>> + interrupts = <31 8>; > >>> + reg-shift = <2>; > >>> + reg-io-width = <4>; > >>> + clock-frequency = <14745600>; > >>> + status = "okay"; > >>> + }; > >>> + > >> > >> And UARTs. > >> > >> Let me know if i'm misunderstanding dts/dtsi split but looking at some > >> of the other SoCs this seems inconsistent to me. > > > > > > It is likely to be true, that technically these are all part of the > > SoC. By examining the hardware, there are no external chips (on either > > base or main board) that looks capable of handling such functions: > > > > https://plus.google.com/photos/103371465418643926605/albums/5820634595801767953 > > > > I made the split with some consideration to other MOXA ART machines, > > that they can be added as a separate file including the same dtsi: > > > > MOXA ART hardware examples: > > > > UC-7112/UC-7110: "SD slot (UC-7112, and UC-7112 Plus only)": > > http://www.moxa.com/product/UC-7112_UC-7110.htm > > > > IA241: "64 MB RAM": > > http://www.moxa.com/product/IA241_IA240.htm > > > > UC-7101-LX: "One 10/100 Mbps Ethernet port": > > http://www.moxa.com/product/UC-7101-LX.htm > > > > > > UC-7112-LX has 32 MB RAM and two ethernet ports. This is why I think > > MAC is good as is, RAM should move out from SoC? > > > > I don't know if they all have a debug UART (I only have access to > > UC-7112-LX), and it's not obvious in specifications. UART can possibly > > be moved into SoC as you say. > > > > I think its going to all be in the SoC. Having it board level would > mean you have a system bus as copper which is not very SoC like (at > least for UART anyway). > > > In cases where SD slot is missing but the register remains in the SoC, > > how is that normally handled? > > > > Soren Brinkmann's recent addition of ethernet to the Zynq SoC > illustrates the concept for a MAC. The two MACs are added to the > shared dtsi but disabled. The board level dts then enables it for the > one which is board populated: > > https://lkml.org/lkml/2013/12/11/434 > > I think its generally applicable to your SD MAC and UART cases. The > tegra20 dtsi illustrates the status = "disabled" concept specifically > for SDHCI. I think it's less SoC vs. non-SoC parts. There are even platforms using more than two levels of includes. IMHO, it's just to avoid duplication. So, stuff that doesn't change ever goes into the lowest level dtsi and then you work your way up. That way people bringing up a board with your part just have to enable the correct set of peripherals and provide board specific properties. You don't want everybody to repeat the same memory map (reg properties), clock references, etc. over and over again in all dtses that use a specific SoC, right? Long story short: I separate by: Properties that are statically defined by the SOC => dtsi. Properties that are defined by the PCB design => board level dts. S?ren ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v4 2/2] ARM: mach-moxart: add MOXA ART SoC device tree files @ 2013-12-17 0:09 ` Sören Brinkmann 0 siblings, 0 replies; 44+ messages in thread From: Sören Brinkmann @ 2013-12-17 0:09 UTC (permalink / raw) To: Peter Crosthwaite Cc: Jonas Jensen, linux-arm-kernel, linux-kernel, devicetree-discuss, arm, Russell King - ARM Linux, Arnd Bergmann, Olof Johansson, devicetree Hi, On Tue, Dec 17, 2013 at 09:53:27AM +1000, Peter Crosthwaite wrote: > On Tue, Dec 17, 2013 at 6:05 AM, Jonas Jensen <jonas.jensen@gmail.com> wrote: > > On 15 December 2013 05:27, Peter Crosthwaite > > <peter.crosthwaite@xilinx.com> wrote: > >>> + sdhci: sdhci@98e00000 { > >>> + compatible = "moxa,moxart-sdhci"; > >>> + reg = <0x98e00000 0x5C>; > >>> + interrupts = <5 0>; > >>> + clocks = <&clk_apb>; > >>> + dmas = <&dma 5>, > >>> + <&dma 5>; > >>> + dma-names = "tx", "rx"; > >>> + }; > >> > >> Is your SDHCI really implemented on the board level? The fact that its > >> reg property is within the same as the SoC range (for your dtsi) > >> suggests the SDHCI is part of the SoC and should perhaps be in the > >> dtsi? > > > >>> + mac1: mac@92000000 { > >>> + compatible = "moxa,moxart-mac"; > >>> + reg = <0x92000000 0x90>; > >>> + interrupts = <27 0>; > >>> + phy-handle = <ðphy1>; > >>> + phy-mode = "mii"; > >>> + }; > >> > >> Same for MACs. > > > >>> + > >>> + uart0: uart@98200000 { > >>> + compatible = "ns16550a"; > >>> + reg = <0x98200000 0x20>; > >>> + interrupts = <31 8>; > >>> + reg-shift = <2>; > >>> + reg-io-width = <4>; > >>> + clock-frequency = <14745600>; > >>> + status = "okay"; > >>> + }; > >>> + > >> > >> And UARTs. > >> > >> Let me know if i'm misunderstanding dts/dtsi split but looking at some > >> of the other SoCs this seems inconsistent to me. > > > > > > It is likely to be true, that technically these are all part of the > > SoC. By examining the hardware, there are no external chips (on either > > base or main board) that looks capable of handling such functions: > > > > https://plus.google.com/photos/103371465418643926605/albums/5820634595801767953 > > > > I made the split with some consideration to other MOXA ART machines, > > that they can be added as a separate file including the same dtsi: > > > > MOXA ART hardware examples: > > > > UC-7112/UC-7110: "SD slot (UC-7112, and UC-7112 Plus only)": > > http://www.moxa.com/product/UC-7112_UC-7110.htm > > > > IA241: "64 MB RAM": > > http://www.moxa.com/product/IA241_IA240.htm > > > > UC-7101-LX: "One 10/100 Mbps Ethernet port": > > http://www.moxa.com/product/UC-7101-LX.htm > > > > > > UC-7112-LX has 32 MB RAM and two ethernet ports. This is why I think > > MAC is good as is, RAM should move out from SoC? > > > > I don't know if they all have a debug UART (I only have access to > > UC-7112-LX), and it's not obvious in specifications. UART can possibly > > be moved into SoC as you say. > > > > I think its going to all be in the SoC. Having it board level would > mean you have a system bus as copper which is not very SoC like (at > least for UART anyway). > > > In cases where SD slot is missing but the register remains in the SoC, > > how is that normally handled? > > > > Soren Brinkmann's recent addition of ethernet to the Zynq SoC > illustrates the concept for a MAC. The two MACs are added to the > shared dtsi but disabled. The board level dts then enables it for the > one which is board populated: > > https://lkml.org/lkml/2013/12/11/434 > > I think its generally applicable to your SD MAC and UART cases. The > tegra20 dtsi illustrates the status = "disabled" concept specifically > for SDHCI. I think it's less SoC vs. non-SoC parts. There are even platforms using more than two levels of includes. IMHO, it's just to avoid duplication. So, stuff that doesn't change ever goes into the lowest level dtsi and then you work your way up. That way people bringing up a board with your part just have to enable the correct set of peripherals and provide board specific properties. You don't want everybody to repeat the same memory map (reg properties), clock references, etc. over and over again in all dtses that use a specific SoC, right? Long story short: I separate by: Properties that are statically defined by the SOC => dtsi. Properties that are defined by the PCB design => board level dts. Sören ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v4 2/2] ARM: mach-moxart: add MOXA ART SoC device tree files 2013-12-13 14:33 ` Jonas Jensen @ 2013-12-22 19:49 ` Olof Johansson -1 siblings, 0 replies; 44+ messages in thread From: Olof Johansson @ 2013-12-22 19:49 UTC (permalink / raw) To: Jonas Jensen Cc: linux-arm-kernel, linux-kernel, devicetree-discuss, arm, linux, arnd Hi, On Fri, Dec 13, 2013 at 03:33:08PM +0100, Jonas Jensen wrote: > Add a generic (dtsi) include file for MOXA ART SoCs. > > Also add a file for UC-7112-LX. > > Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com> Applied to next/dt. Again, please follow up with some of the comments -- in particular the requests to keep the SoC IP blocks in the dtsi file and only enable/disable or amend the entries in the per-board file depending on actual board configuration. But I didn't see a reason to not merge it while that's being cleaned up, etc. -Olof ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v4 2/2] ARM: mach-moxart: add MOXA ART SoC device tree files @ 2013-12-22 19:49 ` Olof Johansson 0 siblings, 0 replies; 44+ messages in thread From: Olof Johansson @ 2013-12-22 19:49 UTC (permalink / raw) To: linux-arm-kernel Hi, On Fri, Dec 13, 2013 at 03:33:08PM +0100, Jonas Jensen wrote: > Add a generic (dtsi) include file for MOXA ART SoCs. > > Also add a file for UC-7112-LX. > > Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com> Applied to next/dt. Again, please follow up with some of the comments -- in particular the requests to keep the SoC IP blocks in the dtsi file and only enable/disable or amend the entries in the per-board file depending on actual board configuration. But I didn't see a reason to not merge it while that's being cleaned up, etc. -Olof ^ permalink raw reply [flat|nested] 44+ messages in thread
end of thread, other threads:[~2013-12-22 19:51 UTC | newest]
Thread overview: 44+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-12-13 14:33 [PATCH v4 0/2] ARM: mach-moxart: add MOXA ART SoC support Jonas Jensen
2013-12-13 14:33 ` Jonas Jensen
2013-12-13 14:33 ` [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files Jonas Jensen
2013-12-13 14:33 ` Jonas Jensen
[not found] ` <1386945188-8316-2-git-send-email-jonas.jensen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-12-13 14:38 ` Fwd: " Jonas Jensen
2013-12-13 16:17 ` Arnd Bergmann
2013-12-13 16:17 ` Arnd Bergmann
2013-12-13 17:23 ` Jonas Jensen
2013-12-13 17:23 ` Jonas Jensen
2013-12-13 19:07 ` Guenter Roeck
2013-12-13 19:07 ` Guenter Roeck
2013-12-14 4:01 ` Arnd Bergmann
2013-12-14 4:01 ` Arnd Bergmann
2013-12-14 8:32 ` Jonas Jensen
2013-12-14 8:32 ` Jonas Jensen
2013-12-14 15:50 ` Guenter Roeck
2013-12-14 15:50 ` Guenter Roeck
2013-12-14 16:26 ` Jonas Jensen
2013-12-14 16:26 ` Jonas Jensen
2013-12-14 18:50 ` Arnd Bergmann
2013-12-14 18:50 ` Arnd Bergmann
2013-12-14 20:14 ` Guenter Roeck
2013-12-14 20:14 ` Guenter Roeck
2013-12-15 0:21 ` Arnd Bergmann
2013-12-15 0:21 ` Arnd Bergmann
2013-12-22 19:48 ` Olof Johansson
2013-12-22 19:48 ` Olof Johansson
2013-12-13 14:33 ` [PATCH v4 2/2] ARM: mach-moxart: add MOXA ART SoC device tree files Jonas Jensen
2013-12-13 14:33 ` Jonas Jensen
[not found] ` <1386945188-8316-3-git-send-email-jonas.jensen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-12-13 14:39 ` Fwd: " Jonas Jensen
2013-12-13 16:17 ` Arnd Bergmann
2013-12-13 16:17 ` Arnd Bergmann
2013-12-15 4:27 ` Peter Crosthwaite
2013-12-15 4:27 ` Peter Crosthwaite
2013-12-16 20:05 ` Jonas Jensen
2013-12-16 20:05 ` Jonas Jensen
2013-12-16 23:53 ` Peter Crosthwaite
2013-12-16 23:53 ` Peter Crosthwaite
2013-12-16 23:53 ` Peter Crosthwaite
2013-12-17 0:09 ` Sören Brinkmann
2013-12-17 0:09 ` Sören Brinkmann
2013-12-17 0:09 ` Sören Brinkmann
2013-12-22 19:49 ` Olof Johansson
2013-12-22 19:49 ` Olof Johansson
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.