* [Patch v4 1/5] Power: reset: keystone-reset: introduce keystone reset driver
2014-05-21 14:27 [Patch v4 0/5] Introduce keystone reset driver Ivan Khoronzhuk
@ 2014-05-21 14:27 ` Ivan Khoronzhuk
2014-05-21 14:27 ` [Patch v4 2/5] Power: reset: add bindings for " Ivan Khoronzhuk
` (4 subsequent siblings)
5 siblings, 0 replies; 13+ messages in thread
From: Ivan Khoronzhuk @ 2014-05-21 14:27 UTC (permalink / raw)
To: dbaryshkov, dwmw2, santosh.shilimkar, arnd, robh+dt, pawel.moll,
mark.rutland, ijc+devicetree, galak, grant.likely
Cc: rdunlap, linux, grygorii.strashko, olof, w-kwok2, sboyd,
devicetree, linux-doc, linux-kernel, linux-arm-kernel,
m-karicheri2, Ivan Khoronzhuk
The keystone SoC can be rebooted in several ways. By external reset
pin, by soft and by watchdogs. To allow keystone SoC reset if
watchdog is triggered we have to enable it in reset mux configuration
register regarding of watchdog configuration. Also we need to set
soft/hard reset we are going to use.
So add keystone reset driver to handle all this stuff.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
---
drivers/power/reset/Kconfig | 8 ++
drivers/power/reset/Makefile | 1 +
drivers/power/reset/keystone-reset.c | 153 +++++++++++++++++++++++++++++++++++
3 files changed, 162 insertions(+)
create mode 100644 drivers/power/reset/keystone-reset.c
diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index fa0e4e0..d095e5b 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -57,3 +57,11 @@ config POWER_RESET_XGENE
depends on POWER_RESET
help
Reboot support for the APM SoC X-Gene Eval boards.
+
+config POWER_RESET_KEYSTONE
+ bool "Keystone reset driver"
+ depends on ARCH_KEYSTONE
+ select MFD_SYSCON
+ help
+ Reboot support for the KEYSTONE SoCs.
+
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index a5b4a77..802a420 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
obj-$(CONFIG_POWER_RESET_RESTART) += restart-poweroff.o
obj-$(CONFIG_POWER_RESET_VEXPRESS) += vexpress-poweroff.o
obj-$(CONFIG_POWER_RESET_XGENE) += xgene-reboot.o
+obj-$(CONFIG_POWER_RESET_KEYSTONE) += keystone-reset.o
diff --git a/drivers/power/reset/keystone-reset.c b/drivers/power/reset/keystone-reset.c
new file mode 100644
index 0000000..39997a1
--- /dev/null
+++ b/drivers/power/reset/keystone-reset.c
@@ -0,0 +1,153 @@
+/*
+ * TI keystone reboot driver
+ *
+ * Copyright (C) 2014 Texas Instruments Incorporated. http://www.ti.com/
+ *
+ * Author: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/reboot.h>
+#include <linux/regmap.h>
+#include <asm/system_misc.h>
+#include <linux/mfd/syscon.h>
+#include <linux/of_platform.h>
+
+#define RSTYPE_RG 0xe4
+#define RSCTRL_RG 0xe8
+#define RSCFG_RG 0xec
+#define RSISO_RG 0xf0
+
+#define RSCTRL_KEY_MASK 0x0000ffff
+#define RSCTRL_RESET_MASK BIT(16)
+#define RSCTRL_KEY 0x5a69
+
+#define RSMUX_OMODE_MASK 0xe
+#define RSMUX_OMODE_RESET_ON 0xa
+#define RSMUX_OMODE_RESET_OFF 0x0
+#define RSMUX_LOCK_MASK 0x1
+#define RSMUX_LOCK_SET 0x1
+#define RSMUX_BASE 0x328
+
+#define RSCFG_RSTYPE_SOFT 0x300f
+#define RSCFG_RSTYPE_HARD 0x0
+
+#define WDT_MUX_NUMBER 0x4
+
+static struct regmap *pllctrl_regs;
+
+/**
+ * rsctrl_enable_rspll_write - enable access to RSCTRL, RSCFG
+ * To be able to access to RSCTRL, RSCFG registers
+ * we have to write a key before
+ */
+static inline int rsctrl_enable_rspll_write(void)
+{
+ return regmap_update_bits(pllctrl_regs, RSCTRL_RG,
+ RSCTRL_KEY_MASK, RSCTRL_KEY);
+}
+
+static void rsctrl_restart(enum reboot_mode mode, const char *cmd)
+{
+ /* enable write access to RSTCTRL */
+ rsctrl_enable_rspll_write();
+
+ /* reset the SOC */
+ regmap_update_bits(pllctrl_regs, RSCTRL_RG,
+ RSCTRL_RESET_MASK, 0);
+}
+
+static struct of_device_id rsctrl_of_match[] = {
+ {.compatible = "ti,keystone-reset", },
+ {},
+};
+
+static int rsctrl_probe(struct platform_device *pdev)
+{
+ int i;
+ int ret;
+ u32 val;
+ unsigned int rg;
+ struct regmap *devctrl_regs;
+ struct device *dev = &pdev->dev;
+ struct device_node *np = dev->of_node;
+
+ if (!np)
+ return -ENODEV;
+
+ /* get regmaps */
+ pllctrl_regs = syscon_regmap_lookup_by_phandle(np, "ti,syscon-pll");
+ if (IS_ERR(pllctrl_regs))
+ return PTR_ERR(pllctrl_regs);
+
+ devctrl_regs = syscon_regmap_lookup_by_phandle(np, "ti,syscon-dev");
+ if (IS_ERR(devctrl_regs))
+ return PTR_ERR(devctrl_regs);
+
+ /* set soft/hard reset */
+ val = of_property_read_bool(np, "ti,soft-reset");
+ val = val ? RSCFG_RSTYPE_SOFT : RSCFG_RSTYPE_HARD;
+
+ ret = rsctrl_enable_rspll_write();
+ if (ret)
+ return ret;
+
+ ret = regmap_write(pllctrl_regs, RSCFG_RG, val);
+ if (ret)
+ return ret;
+
+ arm_pm_restart = rsctrl_restart;
+
+ /* disable a reset isolation for all module clocks */
+ ret = regmap_write(pllctrl_regs, RSISO_RG, 0);
+ if (ret)
+ return ret;
+
+ /* enable a reset for watchdogs from wdt_list */
+ for (i = 0; i < WDT_MUX_NUMBER; i++) {
+ ret = of_property_read_u32_index(np, "ti,wdt_list", i, &val);
+ if (ret == -EOVERFLOW && !i) {
+ dev_err(dev, "ti,wdt_list property has to contain at"
+ "least one entry\n");
+ return -EINVAL;
+ } else if (ret) {
+ break;
+ }
+
+ if (val >= WDT_MUX_NUMBER) {
+ dev_err(dev, "ti,wdt_list property can contain"
+ "only numbers < 4\n");
+ return -EINVAL;
+ }
+
+ rg = RSMUX_BASE + val * 4;
+
+ ret = regmap_update_bits(devctrl_regs, rg, RSMUX_OMODE_MASK,
+ RSMUX_OMODE_RESET_ON |
+ RSMUX_LOCK_SET);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+static struct platform_driver rsctrl_driver = {
+ .probe = rsctrl_probe,
+ .driver = {
+ .owner = THIS_MODULE,
+ .name = KBUILD_MODNAME,
+ .of_match_table = rsctrl_of_match,
+ },
+};
+module_platform_driver(rsctrl_driver);
+
+MODULE_AUTHOR("Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>");
+MODULE_DESCRIPTION("Texas Instruments keystone reset driver");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:" KBUILD_MODNAME);
--
1.8.3.2
^ permalink raw reply related [flat|nested] 13+ messages in thread* [Patch v4 2/5] Power: reset: add bindings for keystone reset driver
2014-05-21 14:27 [Patch v4 0/5] Introduce keystone reset driver Ivan Khoronzhuk
2014-05-21 14:27 ` [Patch v4 1/5] Power: reset: keystone-reset: introduce " Ivan Khoronzhuk
@ 2014-05-21 14:27 ` Ivan Khoronzhuk
2014-05-21 14:50 ` Arnd Bergmann
2014-05-21 14:27 ` [Patch v4 3/5] ARM: keystone: remove redundant reset stuff Ivan Khoronzhuk
` (3 subsequent siblings)
5 siblings, 1 reply; 13+ messages in thread
From: Ivan Khoronzhuk @ 2014-05-21 14:27 UTC (permalink / raw)
To: dbaryshkov, dwmw2, santosh.shilimkar, arnd, robh+dt, pawel.moll,
mark.rutland, ijc+devicetree, galak, grant.likely
Cc: devicetree, grygorii.strashko, linux, linux-doc, w-kwok2, rdunlap,
sboyd, linux-kernel, m-karicheri2, olof, Ivan Khoronzhuk,
linux-arm-kernel
This node is intended to allow SoC reset in case of software reset
or appropriate watchdogs.
The Keystone SoCs can contain up to 4 watchdog timers to reset
SoC. Each watchdog timer event input is connected to the Reset Mux
block. The Reset Mux block can be configured to cause reset or not.
Additionally soft or hard reset can be configured.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
---
.../bindings/power/reset/keystone-reset.txt | 66 ++++++++++++++++++++++
1 file changed, 66 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/reset/keystone-reset.txt
diff --git a/Documentation/devicetree/bindings/power/reset/keystone-reset.txt b/Documentation/devicetree/bindings/power/reset/keystone-reset.txt
new file mode 100644
index 0000000..64cb7b4
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/keystone-reset.txt
@@ -0,0 +1,66 @@
+* Device tree bindings for Texas Instruments keystone reset
+
+This node is intended to allow SoC reset in case of software reset
+of selected watchdogs.
+
+The Keystone SoCs can contain up to 4 watchdog timers to reset
+SoC. Each watchdog timer event input is connected to the Reset Mux
+block. The Reset Mux block can be configured to cause reset or not.
+
+Additionally soft or hard reset can be configured.
+
+Required properties:
+
+- compatible: ti,keystone-reset
+
+- ti,syscon-pll: syscon register range used to access pll controller
+ registers in order to use reset control registers.
+
+- ti,syscon-dev: syscon register range used to access device state
+ control registers in order to use mux block registers
+ for all watchdogs.
+
+Optional properties:
+
+- ti,soft-reset: Boolean option indicating soft reset.
+ By default hard reset is used.
+
+- ti,wdt_list: WDT list that can cause SoC reset. It's not related
+ to WDT driver, it's just needed to enable a SoC related
+ reset that's triggered by one of WDTs. The list is
+ in format: <0>, <2>; It can be in random order and
+ begins from 0 to 3, as keystone can contain up to 4 SoC
+ reset watchdogs and can be in random order.
+
+Example 1:
+Setup keystone reset so that in case software reset or
+WDT0 is triggered it issues hard reset for SoC.
+
+pllctrl: pll_controller {
+ compatible = "syscon";
+ reg = <0x2310000 0x200>;
+};
+
+devctrl: device_state_control {
+ compatible = "syscon";
+ reg = <0x2620000 0x1000>;
+};
+
+rstctrl: reset-controller {
+ compatible = "ti,keystone-reset";
+ ti,syscon-pll = <&pllctrl>;
+ ti,syscon-dev = <&devctrl>;
+ ti,wdt_list = <0>;
+};
+
+Example 2:
+Setup keystone reset so that in case of software reset or
+WDT0 or WDT2 is triggered it issues soft reset for SoC.
+
+rstctrl: reset-controller {
+ compatible = "ti,keystone-reset";
+ ti,syscon-pll = <&pllctrl>;
+ ti,syscon-dev = <&devctrl>;
+ ti,wdt_list = <0>, <2>;
+ ti,soft-reset;
+};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 13+ messages in thread* Re: [Patch v4 2/5] Power: reset: add bindings for keystone reset driver
2014-05-21 14:27 ` [Patch v4 2/5] Power: reset: add bindings for " Ivan Khoronzhuk
@ 2014-05-21 14:50 ` Arnd Bergmann
2014-05-21 16:03 ` Ivan Khoronzhuk
0 siblings, 1 reply; 13+ messages in thread
From: Arnd Bergmann @ 2014-05-21 14:50 UTC (permalink / raw)
To: Ivan Khoronzhuk
Cc: dbaryshkov, dwmw2, santosh.shilimkar, robh+dt, pawel.moll,
mark.rutland, ijc+devicetree, galak, grant.likely, rdunlap, linux,
grygorii.strashko, olof, w-kwok2, sboyd, devicetree, linux-doc,
linux-kernel, linux-arm-kernel, m-karicheri2
On Wednesday 21 May 2014 17:27:31 Ivan Khoronzhuk wrote:
> This node is intended to allow SoC reset in case of software reset
> or appropriate watchdogs.
>
> The Keystone SoCs can contain up to 4 watchdog timers to reset
> SoC. Each watchdog timer event input is connected to the Reset Mux
> block. The Reset Mux block can be configured to cause reset or not.
>
> Additionally soft or hard reset can be configured.
>
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
> ---
> .../bindings/power/reset/keystone-reset.txt | 66 ++++++++++++++++++++++
> 1 file changed, 66 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/reset/keystone-reset.txt
>
> diff --git a/Documentation/devicetree/bindings/power/reset/keystone-reset.txt b/Documentation/devicetree/bindings/power/reset/keystone-reset.txt
> new file mode 100644
> index 0000000..64cb7b4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/reset/keystone-reset.txt
> @@ -0,0 +1,66 @@
> +* Device tree bindings for Texas Instruments keystone reset
> +
> +This node is intended to allow SoC reset in case of software reset
> +of selected watchdogs.
> +
> +The Keystone SoCs can contain up to 4 watchdog timers to reset
> +SoC. Each watchdog timer event input is connected to the Reset Mux
> +block. The Reset Mux block can be configured to cause reset or not.
> +
> +Additionally soft or hard reset can be configured.
> +
> +Required properties:
> +
> +- compatible: ti,keystone-reset
> +
> +- ti,syscon-pll: syscon register range used to access pll controller
> + registers in order to use reset control registers.
> +
> +- ti,syscon-dev: syscon register range used to access device state
> + control registers in order to use mux block registers
> + for all watchdogs.
This should be updated to call these phandles rather than register ranges.
> +Optional properties:
> +
> +- ti,soft-reset: Boolean option indicating soft reset.
> + By default hard reset is used.
> +
> +- ti,wdt_list: WDT list that can cause SoC reset. It's not related
> + to WDT driver, it's just needed to enable a SoC related
> + reset that's triggered by one of WDTs. The list is
> + in format: <0>, <2>; It can be in random order and
> + begins from 0 to 3, as keystone can contain up to 4 SoC
> + reset watchdogs and can be in random order.
> +
> +Example 1:
> +Setup keystone reset so that in case software reset or
> +WDT0 is triggered it issues hard reset for SoC.
> +
> +pllctrl: pll_controller {
> + compatible = "syscon";
> + reg = <0x2310000 0x200>;
> +};
> +
> +devctrl: device_state_control {
> + compatible = "syscon";
> + reg = <0x2620000 0x1000>;
> +};
It's ok to have these in the example, but please also add a binding file
for each one describing what they are, and add a proper "compatible" string
so they can be matched by a high-level device driver if needed.
This could for instance be
compatible = "ti,keystone-1.0-pll-controller", "syscon";
Arnd
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [Patch v4 2/5] Power: reset: add bindings for keystone reset driver
2014-05-21 14:50 ` Arnd Bergmann
@ 2014-05-21 16:03 ` Ivan Khoronzhuk
2014-05-21 16:07 ` Arnd Bergmann
0 siblings, 1 reply; 13+ messages in thread
From: Ivan Khoronzhuk @ 2014-05-21 16:03 UTC (permalink / raw)
To: Arnd Bergmann
Cc: dbaryshkov, dwmw2, santosh.shilimkar, robh+dt, pawel.moll,
mark.rutland, ijc+devicetree, galak, grant.likely, rdunlap, linux,
grygorii.strashko, olof, w-kwok2, sboyd, devicetree, linux-doc,
linux-kernel, linux-arm-kernel, m-karicheri2
On 05/21/2014 05:50 PM, Arnd Bergmann wrote:
> On Wednesday 21 May 2014 17:27:31 Ivan Khoronzhuk wrote:
>> This node is intended to allow SoC reset in case of software reset
>> or appropriate watchdogs.
>>
>> The Keystone SoCs can contain up to 4 watchdog timers to reset
>> SoC. Each watchdog timer event input is connected to the Reset Mux
>> block. The Reset Mux block can be configured to cause reset or not.
>>
>> Additionally soft or hard reset can be configured.
>>
>> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
>> ---
>> .../bindings/power/reset/keystone-reset.txt | 66 ++++++++++++++++++++++
>> 1 file changed, 66 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/power/reset/keystone-reset.txt
>>
>> diff --git a/Documentation/devicetree/bindings/power/reset/keystone-reset.txt b/Documentation/devicetree/bindings/power/reset/keystone-reset.txt
>> new file mode 100644
>> index 0000000..64cb7b4
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/power/reset/keystone-reset.txt
>> @@ -0,0 +1,66 @@
>> +* Device tree bindings for Texas Instruments keystone reset
>> +
>> +This node is intended to allow SoC reset in case of software reset
>> +of selected watchdogs.
>> +
>> +The Keystone SoCs can contain up to 4 watchdog timers to reset
>> +SoC. Each watchdog timer event input is connected to the Reset Mux
>> +block. The Reset Mux block can be configured to cause reset or not.
>> +
>> +Additionally soft or hard reset can be configured.
>> +
>> +Required properties:
>> +
>> +- compatible: ti,keystone-reset
>> +
>> +- ti,syscon-pll: syscon register range used to access pll controller
>> + registers in order to use reset control registers.
>> +
>> +- ti,syscon-dev: syscon register range used to access device state
>> + control registers in order to use mux block registers
>> + for all watchdogs.
> This should be updated to call these phandles rather than register ranges.
>
>> +Optional properties:
>> +
>> +- ti,soft-reset: Boolean option indicating soft reset.
>> + By default hard reset is used.
>> +
>> +- ti,wdt_list: WDT list that can cause SoC reset. It's not related
>> + to WDT driver, it's just needed to enable a SoC related
>> + reset that's triggered by one of WDTs. The list is
>> + in format: <0>, <2>; It can be in random order and
>> + begins from 0 to 3, as keystone can contain up to 4 SoC
>> + reset watchdogs and can be in random order.
>> +
>> +Example 1:
>> +Setup keystone reset so that in case software reset or
>> +WDT0 is triggered it issues hard reset for SoC.
>> +
>> +pllctrl: pll_controller {
>> + compatible = "syscon";
>> + reg = <0x2310000 0x200>;
>> +};
>> +
>> +devctrl: device_state_control {
>> + compatible = "syscon";
>> + reg = <0x2620000 0x1000>;
>> +};
> It's ok to have these in the example, but please also add a binding file
> for each one describing what they are, and add a proper "compatible" string
> so they can be matched by a high-level device driver if needed.
>
> This could for instance be
>
> compatible = "ti,keystone-1.0-pll-controller", "syscon";
Arnd,
I've slightly confused where should I add these bindings.
The main pll controller mostly used by clk driver....
As its register set is used also by reset driver it's logically to put
it to bindings/mfd,
but pll controller in mfd it's strange....
Could you please help to decide where should it be?.
--
Regards,
Ivan Khoronzhuk
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [Patch v4 2/5] Power: reset: add bindings for keystone reset driver
2014-05-21 16:03 ` Ivan Khoronzhuk
@ 2014-05-21 16:07 ` Arnd Bergmann
2014-05-21 16:09 ` Santosh Shilimkar
0 siblings, 1 reply; 13+ messages in thread
From: Arnd Bergmann @ 2014-05-21 16:07 UTC (permalink / raw)
To: Ivan Khoronzhuk
Cc: mark.rutland, devicetree, grygorii.strashko, linux, linux-doc,
pawel.moll, ijc+devicetree, dbaryshkov, rdunlap, sboyd,
linux-kernel, m-karicheri2, olof, robh+dt, santosh.shilimkar,
linux-arm-kernel, galak, grant.likely, dwmw2, w-kwok2
On Wednesday 21 May 2014 19:03:38 Ivan Khoronzhuk wrote:
>
> I've slightly confused where should I add these bindings.
> The main pll controller mostly used by clk driver....
> As its register set is used also by reset driver it's logically to put
> it to bindings/mfd,
> but pll controller in mfd it's strange....
>
> Could you please help to decide where should it be?.
Put it into Documentation/devicetree/bindings/clock/keystone-pll.txt
Arnd
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Patch v4 2/5] Power: reset: add bindings for keystone reset driver
2014-05-21 16:07 ` Arnd Bergmann
@ 2014-05-21 16:09 ` Santosh Shilimkar
0 siblings, 0 replies; 13+ messages in thread
From: Santosh Shilimkar @ 2014-05-21 16:09 UTC (permalink / raw)
To: Arnd Bergmann, Ivan Khoronzhuk
Cc: dbaryshkov, dwmw2, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, grant.likely, rdunlap, linux,
grygorii.strashko, olof, w-kwok2, sboyd, devicetree, linux-doc,
linux-kernel, linux-arm-kernel, m-karicheri2
On Wednesday 21 May 2014 12:07 PM, Arnd Bergmann wrote:
> On Wednesday 21 May 2014 19:03:38 Ivan Khoronzhuk wrote:
>>
>> I've slightly confused where should I add these bindings.
>> The main pll controller mostly used by clk driver....
>> As its register set is used also by reset driver it's logically to put
>> it to bindings/mfd,
>> but pll controller in mfd it's strange....
>>
>> Could you please help to decide where should it be?.
>
> Put it into Documentation/devicetree/bindings/clock/keystone-pll.txt
>
I was just about post the same suggestion. Lets do that.
regards,
Santosh
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Patch v4 3/5] ARM: keystone: remove redundant reset stuff
2014-05-21 14:27 [Patch v4 0/5] Introduce keystone reset driver Ivan Khoronzhuk
2014-05-21 14:27 ` [Patch v4 1/5] Power: reset: keystone-reset: introduce " Ivan Khoronzhuk
2014-05-21 14:27 ` [Patch v4 2/5] Power: reset: add bindings for " Ivan Khoronzhuk
@ 2014-05-21 14:27 ` Ivan Khoronzhuk
2014-05-21 14:27 ` [Patch v4 4/5] ARM: dts: keystone: update reset node to work with reset driver Ivan Khoronzhuk
` (2 subsequent siblings)
5 siblings, 0 replies; 13+ messages in thread
From: Ivan Khoronzhuk @ 2014-05-21 14:27 UTC (permalink / raw)
To: dbaryshkov, dwmw2, santosh.shilimkar, arnd, robh+dt, pawel.moll,
mark.rutland, ijc+devicetree, galak, grant.likely
Cc: devicetree, grygorii.strashko, linux, linux-doc, w-kwok2, rdunlap,
sboyd, linux-kernel, m-karicheri2, olof, Ivan Khoronzhuk,
linux-arm-kernel
Remove reset stuff in flavour of using keystone reset driver:
driver/power/reset/keystone-reset.c
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
---
arch/arm/mach-keystone/keystone.c | 34 ----------------------------------
1 file changed, 34 deletions(-)
diff --git a/arch/arm/mach-keystone/keystone.c b/arch/arm/mach-keystone/keystone.c
index 59b8383..1f9ae89 100644
--- a/arch/arm/mach-keystone/keystone.c
+++ b/arch/arm/mach-keystone/keystone.c
@@ -26,11 +26,6 @@
#include "keystone.h"
-#define PLL_RESET_WRITE_KEY_MASK 0xffff0000
-#define PLL_RESET_WRITE_KEY 0x5a69
-#define PLL_RESET BIT(16)
-
-static void __iomem *keystone_rstctrl;
static struct notifier_block platform_nb;
static unsigned long keystone_dma_pfn_offset __read_mostly;
@@ -55,16 +50,6 @@ static int keystone_platform_notifier(struct notifier_block *nb,
static void __init keystone_init(void)
{
- struct device_node *node;
-
- node = of_find_compatible_node(NULL, NULL, "ti,keystone-reset");
- if (WARN_ON(!node))
- pr_warn("ti,keystone-reset node undefined\n");
-
- keystone_rstctrl = of_iomap(node, 0);
- if (WARN_ON(!keystone_rstctrl))
- pr_warn("ti,keystone-reset iomap error\n");
-
keystone_pm_runtime_init();
if (platform_nb.notifier_call)
bus_register_notifier(&platform_bus_type, &platform_nb);
@@ -123,24 +108,6 @@ static const char *keystone_match[] __initconst = {
NULL,
};
-void keystone_restart(enum reboot_mode mode, const char *cmd)
-{
- u32 val;
-
- BUG_ON(!keystone_rstctrl);
-
- /* Enable write access to RSTCTRL */
- val = readl(keystone_rstctrl);
- val &= PLL_RESET_WRITE_KEY_MASK;
- val |= PLL_RESET_WRITE_KEY;
- writel(val, keystone_rstctrl);
-
- /* Reset the SOC */
- val = readl(keystone_rstctrl);
- val &= ~PLL_RESET;
- writel(val, keystone_rstctrl);
-}
-
DT_MACHINE_START(KEYSTONE, "Keystone")
#if defined(CONFIG_ZONE_DMA) && defined(CONFIG_ARM_LPAE)
.dma_zone_size = SZ_2G,
@@ -148,6 +115,5 @@ DT_MACHINE_START(KEYSTONE, "Keystone")
.smp = smp_ops(keystone_smp_ops),
.init_machine = keystone_init,
.dt_compat = keystone_match,
- .restart = keystone_restart,
.init_meminfo = keystone_init_meminfo,
MACHINE_END
--
1.8.3.2
^ permalink raw reply related [flat|nested] 13+ messages in thread* [Patch v4 4/5] ARM: dts: keystone: update reset node to work with reset driver
2014-05-21 14:27 [Patch v4 0/5] Introduce keystone reset driver Ivan Khoronzhuk
` (2 preceding siblings ...)
2014-05-21 14:27 ` [Patch v4 3/5] ARM: keystone: remove redundant reset stuff Ivan Khoronzhuk
@ 2014-05-21 14:27 ` Ivan Khoronzhuk
2014-05-21 14:50 ` Arnd Bergmann
2014-05-21 14:27 ` [Patch v4 5/5] ARM: keystone: enable reset driver support Ivan Khoronzhuk
2014-05-21 14:52 ` [Patch v4 0/5] Introduce keystone reset driver Arnd Bergmann
5 siblings, 1 reply; 13+ messages in thread
From: Ivan Khoronzhuk @ 2014-05-21 14:27 UTC (permalink / raw)
To: dbaryshkov, dwmw2, santosh.shilimkar, arnd, robh+dt, pawel.moll,
mark.rutland, ijc+devicetree, galak, grant.likely
Cc: rdunlap, linux, grygorii.strashko, olof, w-kwok2, sboyd,
devicetree, linux-doc, linux-kernel, linux-arm-kernel,
m-karicheri2, Ivan Khoronzhuk
The keystone driver requires the next additional properties:
"ti,syscon-pll" - syscon register range used to access pll controller
registers in order to use reset control registers.
"ti,syscon-dev" - syscon register range used to access device state
control registers in order to use mux block
registers for all watchdogs.
"ti,wdt_list" - option to declare what watchdog are used to reboot
the SoC, so set "0" WDT as default.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
---
arch/arm/boot/dts/keystone.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index 8b899ba..783da60 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -78,7 +78,9 @@
rstctrl: reset-controller {
compatible = "ti,keystone-reset";
- reg = <0x023100e8 4>; /* pll reset control reg */
+ ti,syscon-pll = <&pllctrl>;
+ ti,syscon-dev = <&devctrl>;
+ ti,wdt_list = <0>;
};
/include/ "keystone-clocks.dtsi"
--
1.8.3.2
^ permalink raw reply related [flat|nested] 13+ messages in thread* Re: [Patch v4 4/5] ARM: dts: keystone: update reset node to work with reset driver
2014-05-21 14:27 ` [Patch v4 4/5] ARM: dts: keystone: update reset node to work with reset driver Ivan Khoronzhuk
@ 2014-05-21 14:50 ` Arnd Bergmann
2014-05-21 16:05 ` Ivan Khoronzhuk
0 siblings, 1 reply; 13+ messages in thread
From: Arnd Bergmann @ 2014-05-21 14:50 UTC (permalink / raw)
To: Ivan Khoronzhuk
Cc: dbaryshkov, dwmw2, santosh.shilimkar, robh+dt, pawel.moll,
mark.rutland, ijc+devicetree, galak, grant.likely, rdunlap, linux,
grygorii.strashko, olof, w-kwok2, sboyd, devicetree, linux-doc,
linux-kernel, linux-arm-kernel, m-karicheri2
On Wednesday 21 May 2014 17:27:33 Ivan Khoronzhuk wrote:
> The keystone driver requires the next additional properties:
>
> "ti,syscon-pll" - syscon register range used to access pll controller
> registers in order to use reset control registers.
> "ti,syscon-dev" - syscon register range used to access device state
> control registers in order to use mux block
> registers for all watchdogs.
>
> "ti,wdt_list" - option to declare what watchdog are used to reboot
> the SoC, so set "0" WDT as default.
>
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
Same comment as what I had for the binding: it's not a register range
any more, but a phandle for a device.
> ---
> arch/arm/boot/dts/keystone.dtsi | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
> index 8b899ba..783da60 100644
> --- a/arch/arm/boot/dts/keystone.dtsi
> +++ b/arch/arm/boot/dts/keystone.dtsi
> @@ -78,7 +78,9 @@
>
> rstctrl: reset-controller {
> compatible = "ti,keystone-reset";
> - reg = <0x023100e8 4>; /* pll reset control reg */
> + ti,syscon-pll = <&pllctrl>;
> + ti,syscon-dev = <&devctrl>;
> + ti,wdt_list = <0>;
> };
>
I don't see a definition for the two labels, so this will cause a
build error. It makes sense to add them in the same patch.
Arnd
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [Patch v4 4/5] ARM: dts: keystone: update reset node to work with reset driver
2014-05-21 14:50 ` Arnd Bergmann
@ 2014-05-21 16:05 ` Ivan Khoronzhuk
0 siblings, 0 replies; 13+ messages in thread
From: Ivan Khoronzhuk @ 2014-05-21 16:05 UTC (permalink / raw)
To: Arnd Bergmann
Cc: dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w, dwmw2-wEGCiKHe2LqWVfeAwA7xHQ,
santosh.shilimkar-l0cyMroinI0, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
pawel.moll-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
galak-sgV2jX0FEOL9JmXXK+q4OQ, grant.likely-QSEj5FYQhm4dnm+yROfE0A,
rdunlap-wEGCiKHe2LqWVfeAwA7xHQ, linux-lFZ/pmaqli7XmaaqVzeoHQ,
grygorii.strashko-l0cyMroinI0, olof-nZhT3qVonbNeoWH0uzbU5w,
w-kwok2-l0cyMroinI0, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
m-karicheri2-l0cyMroinI0
On 05/21/2014 05:50 PM, Arnd Bergmann wrote:
> On Wednesday 21 May 2014 17:27:33 Ivan Khoronzhuk wrote:
>> The keystone driver requires the next additional properties:
>>
>> "ti,syscon-pll" - syscon register range used to access pll controller
>> registers in order to use reset control registers.
>> "ti,syscon-dev" - syscon register range used to access device state
>> control registers in order to use mux block
>> registers for all watchdogs.
>>
>> "ti,wdt_list" - option to declare what watchdog are used to reboot
>> the SoC, so set "0" WDT as default.
>>
>> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk-l0cyMroinI0@public.gmane.org>
> Same comment as what I had for the binding: it's not a register range
> any more, but a phandle for a device.
>
>> ---
>> arch/arm/boot/dts/keystone.dtsi | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
>> index 8b899ba..783da60 100644
>> --- a/arch/arm/boot/dts/keystone.dtsi
>> +++ b/arch/arm/boot/dts/keystone.dtsi
>> @@ -78,7 +78,9 @@
>>
>> rstctrl: reset-controller {
>> compatible = "ti,keystone-reset";
>> - reg = <0x023100e8 4>; /* pll reset control reg */
>> + ti,syscon-pll = <&pllctrl>;
>> + ti,syscon-dev = <&devctrl>;
>> + ti,wdt_list = <0>;
>> };
>>
> I don't see a definition for the two labels, so this will cause a
> build error. It makes sense to add them in the same patch.
>
> Arnd
Thanks,
I'll correct
--
Regards,
Ivan Khoronzhuk
--
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 [flat|nested] 13+ messages in thread
* [Patch v4 5/5] ARM: keystone: enable reset driver support
2014-05-21 14:27 [Patch v4 0/5] Introduce keystone reset driver Ivan Khoronzhuk
` (3 preceding siblings ...)
2014-05-21 14:27 ` [Patch v4 4/5] ARM: dts: keystone: update reset node to work with reset driver Ivan Khoronzhuk
@ 2014-05-21 14:27 ` Ivan Khoronzhuk
2014-05-21 14:52 ` [Patch v4 0/5] Introduce keystone reset driver Arnd Bergmann
5 siblings, 0 replies; 13+ messages in thread
From: Ivan Khoronzhuk @ 2014-05-21 14:27 UTC (permalink / raw)
To: dbaryshkov, dwmw2, santosh.shilimkar, arnd, robh+dt, pawel.moll,
mark.rutland, ijc+devicetree, galak, grant.likely
Cc: rdunlap, linux, grygorii.strashko, olof, w-kwok2, sboyd,
devicetree, linux-doc, linux-kernel, linux-arm-kernel,
m-karicheri2, Ivan Khoronzhuk
Enable reset driver support in order to have opportunity
to reboot SoC by watchdog and by software.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
---
arch/arm/configs/keystone_defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/configs/keystone_defconfig b/arch/arm/configs/keystone_defconfig
index 07b4327..dc0da3f 100644
--- a/arch/arm/configs/keystone_defconfig
+++ b/arch/arm/configs/keystone_defconfig
@@ -132,6 +132,9 @@ CONFIG_SPI=y
CONFIG_SPI_DAVINCI=y
CONFIG_SPI_SPIDEV=y
# CONFIG_HWMON is not set
+CONFIG_POWER_SUPPLY=y
+CONFIG_POWER_RESET=y
+CONFIG_POWER_RESET_KEYSTONE=y
CONFIG_WATCHDOG=y
CONFIG_WATCHDOG_CORE=y
CONFIG_DAVINCI_WATCHDOG=y
--
1.8.3.2
^ permalink raw reply related [flat|nested] 13+ messages in thread* Re: [Patch v4 0/5] Introduce keystone reset driver
2014-05-21 14:27 [Patch v4 0/5] Introduce keystone reset driver Ivan Khoronzhuk
` (4 preceding siblings ...)
2014-05-21 14:27 ` [Patch v4 5/5] ARM: keystone: enable reset driver support Ivan Khoronzhuk
@ 2014-05-21 14:52 ` Arnd Bergmann
5 siblings, 0 replies; 13+ messages in thread
From: Arnd Bergmann @ 2014-05-21 14:52 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Ivan Khoronzhuk, dbaryshkov, dwmw2, santosh.shilimkar, robh+dt,
pawel.moll, mark.rutland, ijc+devicetree, galak, grant.likely,
devicetree, grygorii.strashko, linux, linux-doc, w-kwok2, rdunlap,
sboyd, linux-kernel, m-karicheri2, olof
On Wednesday 21 May 2014 17:27:29 Ivan Khoronzhuk wrote:
> These patches introduce keystone reset driver.
>
> The keystone SoC can be rebooted in several ways. By external reset
> pin, by soft and by watchdogs. This driver allows software reset and reset
> by one of the watchdogs. Also added opportunity to set soft/hard reset type.
>
> Based on linux-next/master
Hi Ivan,
The code looks good to me now, but I have some comments about the
binding. Patches 1, 3 and 5
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Thanks for the quick update.
^ permalink raw reply [flat|nested] 13+ messages in thread