| Message ID | 1386945188-8316-2-git-send-email-jonas.jensen@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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
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
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 >
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
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
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
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
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
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
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
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
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
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