* [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
* [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
* 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
* 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 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 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 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 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
* 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
* [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
(?)
@ 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
* 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
* [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 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
* 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.