Re: [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files
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 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files
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.jen...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files
On 14 December 2013 16:50, Guenter Roeck 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files
On 12/14/2013 12:32 AM, Jonas Jensen wrote: On 13 December 2013 20:07, Guenter Roeck 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files
On 13 December 2013 20:07, Guenter Roeck 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files
On 13 December 2013 20:07, Guenter Roeck li...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files
On 12/14/2013 12:32 AM, Jonas Jensen wrote: On 13 December 2013 20:07, Guenter Roeck li...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files
On 14 December 2013 16:50, Guenter Roeck li...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files
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 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files
On Fri, Dec 13, 2013 at 06:23:44PM +0100, Jonas Jensen wrote: > On 13 December 2013 17:17, Arnd Bergmann 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files
On 13 December 2013 17:17, Arnd Bergmann 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files
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
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
> diff --git a/arch/arm/configs/moxart_defconfig
> b/arch/arm/configs/moxart_defconfig
> new file mode 100644
> index 000..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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files
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.jen...@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 a...@arndb.de
diff --git a/arch/arm/configs/moxart_defconfig
b/arch/arm/configs/moxart_defconfig
new file mode 100644
index 000..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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files
On 13 December 2013 17:17, Arnd Bergmann a...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files
On Fri, Dec 13, 2013 at 06:23:44PM +0100, Jonas Jensen wrote: On 13 December 2013 17:17, Arnd Bergmann a...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files
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 a...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
