* [Patch v3 0/5] Introduce keystone reset driver
@ 2014-05-19 10:25 ` Ivan Khoronzhuk
0 siblings, 0 replies; 42+ messages in thread
From: Ivan Khoronzhuk @ 2014-05-19 10:25 UTC (permalink / raw)
To: dbaryshkov, dwmw2, santosh.shilimkar, robh+dt, pawel.moll,
mark.rutland, ijc+devicetree, galak, grant.likely
Cc: arnd, rdunlap, linux, grygorii.strashko, olof, w-kwok2, sboyd,
devicetree, linux-doc, linux-kernel, linux-arm-kernel,
Ivan Khoronzhuk
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 v3.15-rc5
v2..v3
Power: reset: keystone-reset: introduce keystone reset driver
- no functional changes, only sanity
Power: reset: add bindings for keystone reset driver
- corrected WDT numeration in examples
- extended description of wdt_list property
v1..v2
- re basedon on v3.15-rc1 without changes
Ivan Khoronzhuk (5):
Power: reset: keystone-reset: introduce keystone reset driver
Power: reset: add bindings for keystone reset driver
ARM: keystone: remove redundant reset stuff
ARM: dts: keystone: update reset node to work with reset driver
ARM: keystone: enable reset driver support
.../bindings/power/reset/keystone-reset.txt | 61 ++++++++
arch/arm/boot/dts/keystone.dtsi | 4 +-
arch/arm/configs/keystone_defconfig | 3 +
arch/arm/mach-keystone/keystone.c | 35 -----
drivers/power/reset/Kconfig | 7 +
drivers/power/reset/Makefile | 1 +
drivers/power/reset/keystone-reset.c | 171 +++++++++++++++++++++
7 files changed, 246 insertions(+), 36 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power/reset/keystone-reset.txt
create mode 100644 drivers/power/reset/keystone-reset.c
--
1.8.3.2
^ permalink raw reply [flat|nested] 42+ messages in thread
* [Patch v3 0/5] Introduce keystone reset driver
@ 2014-05-19 10:25 ` Ivan Khoronzhuk
0 siblings, 0 replies; 42+ messages in thread
From: Ivan Khoronzhuk @ 2014-05-19 10:25 UTC (permalink / raw)
To: 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
Cc: arnd-r2nGTMty4D4, 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,
Ivan Khoronzhuk
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 v3.15-rc5
v2..v3
Power: reset: keystone-reset: introduce keystone reset driver
- no functional changes, only sanity
Power: reset: add bindings for keystone reset driver
- corrected WDT numeration in examples
- extended description of wdt_list property
v1..v2
- re basedon on v3.15-rc1 without changes
Ivan Khoronzhuk (5):
Power: reset: keystone-reset: introduce keystone reset driver
Power: reset: add bindings for keystone reset driver
ARM: keystone: remove redundant reset stuff
ARM: dts: keystone: update reset node to work with reset driver
ARM: keystone: enable reset driver support
.../bindings/power/reset/keystone-reset.txt | 61 ++++++++
arch/arm/boot/dts/keystone.dtsi | 4 +-
arch/arm/configs/keystone_defconfig | 3 +
arch/arm/mach-keystone/keystone.c | 35 -----
drivers/power/reset/Kconfig | 7 +
drivers/power/reset/Makefile | 1 +
drivers/power/reset/keystone-reset.c | 171 +++++++++++++++++++++
7 files changed, 246 insertions(+), 36 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power/reset/keystone-reset.txt
create mode 100644 drivers/power/reset/keystone-reset.c
--
1.8.3.2
--
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] 42+ messages in thread
* [Patch v3 0/5] Introduce keystone reset driver
@ 2014-05-19 10:25 ` Ivan Khoronzhuk
0 siblings, 0 replies; 42+ messages in thread
From: Ivan Khoronzhuk @ 2014-05-19 10:25 UTC (permalink / raw)
To: linux-arm-kernel
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 v3.15-rc5
v2..v3
Power: reset: keystone-reset: introduce keystone reset driver
- no functional changes, only sanity
Power: reset: add bindings for keystone reset driver
- corrected WDT numeration in examples
- extended description of wdt_list property
v1..v2
- re basedon on v3.15-rc1 without changes
Ivan Khoronzhuk (5):
Power: reset: keystone-reset: introduce keystone reset driver
Power: reset: add bindings for keystone reset driver
ARM: keystone: remove redundant reset stuff
ARM: dts: keystone: update reset node to work with reset driver
ARM: keystone: enable reset driver support
.../bindings/power/reset/keystone-reset.txt | 61 ++++++++
arch/arm/boot/dts/keystone.dtsi | 4 +-
arch/arm/configs/keystone_defconfig | 3 +
arch/arm/mach-keystone/keystone.c | 35 -----
drivers/power/reset/Kconfig | 7 +
drivers/power/reset/Makefile | 1 +
drivers/power/reset/keystone-reset.c | 171 +++++++++++++++++++++
7 files changed, 246 insertions(+), 36 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power/reset/keystone-reset.txt
create mode 100644 drivers/power/reset/keystone-reset.c
--
1.8.3.2
^ permalink raw reply [flat|nested] 42+ messages in thread
* [Patch v3 1/5] Power: reset: keystone-reset: introduce keystone reset driver
2014-05-19 10:25 ` Ivan Khoronzhuk
(?)
@ 2014-05-19 10:25 ` Ivan Khoronzhuk
-1 siblings, 0 replies; 42+ messages in thread
From: Ivan Khoronzhuk @ 2014-05-19 10:25 UTC (permalink / raw)
To: dbaryshkov, dwmw2, santosh.shilimkar, robh+dt, pawel.moll,
mark.rutland, ijc+devicetree, galak, grant.likely
Cc: arnd, rdunlap, linux, grygorii.strashko, olof, w-kwok2, sboyd,
devicetree, linux-doc, linux-kernel, linux-arm-kernel,
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 | 7 ++
drivers/power/reset/Makefile | 1 +
drivers/power/reset/keystone-reset.c | 171 +++++++++++++++++++++++++++++++++++
3 files changed, 179 insertions(+)
create mode 100644 drivers/power/reset/keystone-reset.c
diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index fa0e4e0..4d2d3d8 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -57,3 +57,10 @@ 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
+ 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..3e44040
--- /dev/null
+++ b/drivers/power/reset/keystone-reset.c
@@ -0,0 +1,171 @@
+/*
+ * 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 <asm/system_misc.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+
+#define RSTYPE_RG 0x0
+#define RSCTRL_RG 0x4
+#define RSCFG_RG 0x8
+#define RSISO_RG 0xc
+
+#define RSCTRL_KEY_MASK 0xffff0000
+#define RSCTRL_KEY 0x5a69
+#define RSCTRL_RESET BIT(16)
+
+#define RSMUX_OMODE_MASK 0xe
+#define RSMUX_OMODE_RESET_SOC 0xa
+#define RSMUX_OMODE_RESET_OFF 0x0
+#define RSMUX_LOCK_MASK 0x1
+#define RSMUX_LOCK_SET 0x1
+
+#define RSCFG_RSTYPE_SOFT 0x300f
+#define RSCFG_RSTYPE_HARD 0x0
+
+#define WDT_MUX_NUMBER 0x4
+
+static void __iomem *rspll_base;
+
+/**
+ * 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 void rsctrl_enable_rspll_write(void)
+{
+ u32 val;
+ void __iomem *rstctrl_rg;
+
+ rstctrl_rg = rspll_base + RSCTRL_RG;
+ val = readl(rstctrl_rg);
+ val &= RSCTRL_KEY_MASK;
+ val |= RSCTRL_KEY;
+ writel(val, rstctrl_rg);
+}
+
+static void rsctrl_restart(enum reboot_mode mode, const char *cmd)
+{
+ u32 val;
+ void __iomem *rstctrl;
+
+ /* enable write access to RSTCTRL */
+ rsctrl_enable_rspll_write();
+
+ /* reset the SOC */
+ rstctrl = rspll_base + RSCTRL_RG;
+ val = readl(rstctrl);
+ val &= ~RSCTRL_RESET;
+ writel(val, rstctrl);
+}
+
+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;
+ void __iomem *rg;
+ struct resource *res;
+ void __iomem *rsmux_base;
+ struct device *dev = &pdev->dev;
+ struct device_node *np = dev->of_node;
+
+ if (!np)
+ return -ENODEV;
+
+ i = of_property_match_string(np, "reg-names", "pllregs");
+ res = platform_get_resource(pdev, IORESOURCE_MEM, i);
+ rspll_base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(rspll_base))
+ return PTR_ERR(rspll_base);
+
+ i = of_property_match_string(np, "reg-names", "muxregs");
+ res = platform_get_resource(pdev, IORESOURCE_MEM, i);
+ rsmux_base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(rsmux_base))
+ return PTR_ERR(rsmux_base);
+
+ /* set soft/hard reset */
+ val = of_property_read_bool(np, "ti,soft-reset");
+ val = val ? RSCFG_RSTYPE_SOFT : RSCFG_RSTYPE_HARD;
+
+ rsctrl_enable_rspll_write();
+ writel(val, rspll_base + RSCFG_RG);
+
+ arm_pm_restart = rsctrl_restart;
+
+ /* disable reset isolation for all module clocks */
+ writel(0, rspll_base + RSISO_RG);
+
+ /* enable reset for watchdogs from 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;
+
+ val = readl(rg);
+ val &= ~RSMUX_OMODE_MASK;
+ val |= RSMUX_OMODE_RESET_SOC | RSMUX_LOCK_SET;
+ writel(val, rg);
+ }
+
+ /* disable reset for watchdogs from not list */
+ for (i = 0; i < WDT_MUX_NUMBER; i++) {
+ rg = rsmux_base + i * 4;
+
+ val = readl(rg);
+ if (!(val & RSMUX_LOCK_MASK)) {
+ val &= ~RSMUX_OMODE_MASK;
+ val |= RSMUX_OMODE_RESET_OFF | RSMUX_LOCK_SET;
+ writel(val, rg);
+ }
+ }
+
+ devm_iounmap(dev, rsmux_base);
+ 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] 42+ messages in thread
* [Patch v3 1/5] Power: reset: keystone-reset: introduce keystone reset driver
@ 2014-05-19 10:25 ` Ivan Khoronzhuk
0 siblings, 0 replies; 42+ messages in thread
From: Ivan Khoronzhuk @ 2014-05-19 10:25 UTC (permalink / raw)
To: dbaryshkov, dwmw2, santosh.shilimkar, robh+dt, pawel.moll,
mark.rutland, ijc+devicetree, galak, grant.likely
Cc: devicetree, grygorii.strashko, linux, arnd, linux-doc, w-kwok2,
rdunlap, sboyd, linux-kernel, olof, Ivan Khoronzhuk,
linux-arm-kernel
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 | 7 ++
drivers/power/reset/Makefile | 1 +
drivers/power/reset/keystone-reset.c | 171 +++++++++++++++++++++++++++++++++++
3 files changed, 179 insertions(+)
create mode 100644 drivers/power/reset/keystone-reset.c
diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index fa0e4e0..4d2d3d8 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -57,3 +57,10 @@ 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
+ 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..3e44040
--- /dev/null
+++ b/drivers/power/reset/keystone-reset.c
@@ -0,0 +1,171 @@
+/*
+ * 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 <asm/system_misc.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+
+#define RSTYPE_RG 0x0
+#define RSCTRL_RG 0x4
+#define RSCFG_RG 0x8
+#define RSISO_RG 0xc
+
+#define RSCTRL_KEY_MASK 0xffff0000
+#define RSCTRL_KEY 0x5a69
+#define RSCTRL_RESET BIT(16)
+
+#define RSMUX_OMODE_MASK 0xe
+#define RSMUX_OMODE_RESET_SOC 0xa
+#define RSMUX_OMODE_RESET_OFF 0x0
+#define RSMUX_LOCK_MASK 0x1
+#define RSMUX_LOCK_SET 0x1
+
+#define RSCFG_RSTYPE_SOFT 0x300f
+#define RSCFG_RSTYPE_HARD 0x0
+
+#define WDT_MUX_NUMBER 0x4
+
+static void __iomem *rspll_base;
+
+/**
+ * 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 void rsctrl_enable_rspll_write(void)
+{
+ u32 val;
+ void __iomem *rstctrl_rg;
+
+ rstctrl_rg = rspll_base + RSCTRL_RG;
+ val = readl(rstctrl_rg);
+ val &= RSCTRL_KEY_MASK;
+ val |= RSCTRL_KEY;
+ writel(val, rstctrl_rg);
+}
+
+static void rsctrl_restart(enum reboot_mode mode, const char *cmd)
+{
+ u32 val;
+ void __iomem *rstctrl;
+
+ /* enable write access to RSTCTRL */
+ rsctrl_enable_rspll_write();
+
+ /* reset the SOC */
+ rstctrl = rspll_base + RSCTRL_RG;
+ val = readl(rstctrl);
+ val &= ~RSCTRL_RESET;
+ writel(val, rstctrl);
+}
+
+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;
+ void __iomem *rg;
+ struct resource *res;
+ void __iomem *rsmux_base;
+ struct device *dev = &pdev->dev;
+ struct device_node *np = dev->of_node;
+
+ if (!np)
+ return -ENODEV;
+
+ i = of_property_match_string(np, "reg-names", "pllregs");
+ res = platform_get_resource(pdev, IORESOURCE_MEM, i);
+ rspll_base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(rspll_base))
+ return PTR_ERR(rspll_base);
+
+ i = of_property_match_string(np, "reg-names", "muxregs");
+ res = platform_get_resource(pdev, IORESOURCE_MEM, i);
+ rsmux_base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(rsmux_base))
+ return PTR_ERR(rsmux_base);
+
+ /* set soft/hard reset */
+ val = of_property_read_bool(np, "ti,soft-reset");
+ val = val ? RSCFG_RSTYPE_SOFT : RSCFG_RSTYPE_HARD;
+
+ rsctrl_enable_rspll_write();
+ writel(val, rspll_base + RSCFG_RG);
+
+ arm_pm_restart = rsctrl_restart;
+
+ /* disable reset isolation for all module clocks */
+ writel(0, rspll_base + RSISO_RG);
+
+ /* enable reset for watchdogs from 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;
+
+ val = readl(rg);
+ val &= ~RSMUX_OMODE_MASK;
+ val |= RSMUX_OMODE_RESET_SOC | RSMUX_LOCK_SET;
+ writel(val, rg);
+ }
+
+ /* disable reset for watchdogs from not list */
+ for (i = 0; i < WDT_MUX_NUMBER; i++) {
+ rg = rsmux_base + i * 4;
+
+ val = readl(rg);
+ if (!(val & RSMUX_LOCK_MASK)) {
+ val &= ~RSMUX_OMODE_MASK;
+ val |= RSMUX_OMODE_RESET_OFF | RSMUX_LOCK_SET;
+ writel(val, rg);
+ }
+ }
+
+ devm_iounmap(dev, rsmux_base);
+ 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] 42+ messages in thread
* [Patch v3 1/5] Power: reset: keystone-reset: introduce keystone reset driver
@ 2014-05-19 10:25 ` Ivan Khoronzhuk
0 siblings, 0 replies; 42+ messages in thread
From: Ivan Khoronzhuk @ 2014-05-19 10:25 UTC (permalink / raw)
To: linux-arm-kernel
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 | 7 ++
drivers/power/reset/Makefile | 1 +
drivers/power/reset/keystone-reset.c | 171 +++++++++++++++++++++++++++++++++++
3 files changed, 179 insertions(+)
create mode 100644 drivers/power/reset/keystone-reset.c
diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index fa0e4e0..4d2d3d8 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -57,3 +57,10 @@ 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
+ 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..3e44040
--- /dev/null
+++ b/drivers/power/reset/keystone-reset.c
@@ -0,0 +1,171 @@
+/*
+ * 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 <asm/system_misc.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+
+#define RSTYPE_RG 0x0
+#define RSCTRL_RG 0x4
+#define RSCFG_RG 0x8
+#define RSISO_RG 0xc
+
+#define RSCTRL_KEY_MASK 0xffff0000
+#define RSCTRL_KEY 0x5a69
+#define RSCTRL_RESET BIT(16)
+
+#define RSMUX_OMODE_MASK 0xe
+#define RSMUX_OMODE_RESET_SOC 0xa
+#define RSMUX_OMODE_RESET_OFF 0x0
+#define RSMUX_LOCK_MASK 0x1
+#define RSMUX_LOCK_SET 0x1
+
+#define RSCFG_RSTYPE_SOFT 0x300f
+#define RSCFG_RSTYPE_HARD 0x0
+
+#define WDT_MUX_NUMBER 0x4
+
+static void __iomem *rspll_base;
+
+/**
+ * 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 void rsctrl_enable_rspll_write(void)
+{
+ u32 val;
+ void __iomem *rstctrl_rg;
+
+ rstctrl_rg = rspll_base + RSCTRL_RG;
+ val = readl(rstctrl_rg);
+ val &= RSCTRL_KEY_MASK;
+ val |= RSCTRL_KEY;
+ writel(val, rstctrl_rg);
+}
+
+static void rsctrl_restart(enum reboot_mode mode, const char *cmd)
+{
+ u32 val;
+ void __iomem *rstctrl;
+
+ /* enable write access to RSTCTRL */
+ rsctrl_enable_rspll_write();
+
+ /* reset the SOC */
+ rstctrl = rspll_base + RSCTRL_RG;
+ val = readl(rstctrl);
+ val &= ~RSCTRL_RESET;
+ writel(val, rstctrl);
+}
+
+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;
+ void __iomem *rg;
+ struct resource *res;
+ void __iomem *rsmux_base;
+ struct device *dev = &pdev->dev;
+ struct device_node *np = dev->of_node;
+
+ if (!np)
+ return -ENODEV;
+
+ i = of_property_match_string(np, "reg-names", "pllregs");
+ res = platform_get_resource(pdev, IORESOURCE_MEM, i);
+ rspll_base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(rspll_base))
+ return PTR_ERR(rspll_base);
+
+ i = of_property_match_string(np, "reg-names", "muxregs");
+ res = platform_get_resource(pdev, IORESOURCE_MEM, i);
+ rsmux_base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(rsmux_base))
+ return PTR_ERR(rsmux_base);
+
+ /* set soft/hard reset */
+ val = of_property_read_bool(np, "ti,soft-reset");
+ val = val ? RSCFG_RSTYPE_SOFT : RSCFG_RSTYPE_HARD;
+
+ rsctrl_enable_rspll_write();
+ writel(val, rspll_base + RSCFG_RG);
+
+ arm_pm_restart = rsctrl_restart;
+
+ /* disable reset isolation for all module clocks */
+ writel(0, rspll_base + RSISO_RG);
+
+ /* enable reset for watchdogs from 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;
+
+ val = readl(rg);
+ val &= ~RSMUX_OMODE_MASK;
+ val |= RSMUX_OMODE_RESET_SOC | RSMUX_LOCK_SET;
+ writel(val, rg);
+ }
+
+ /* disable reset for watchdogs from not list */
+ for (i = 0; i < WDT_MUX_NUMBER; i++) {
+ rg = rsmux_base + i * 4;
+
+ val = readl(rg);
+ if (!(val & RSMUX_LOCK_MASK)) {
+ val &= ~RSMUX_OMODE_MASK;
+ val |= RSMUX_OMODE_RESET_OFF | RSMUX_LOCK_SET;
+ writel(val, rg);
+ }
+ }
+
+ devm_iounmap(dev, rsmux_base);
+ 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] 42+ messages in thread
* [Patch v3 2/5] Power: reset: add bindings for keystone reset driver
2014-05-19 10:25 ` Ivan Khoronzhuk
(?)
@ 2014-05-19 10:25 ` Ivan Khoronzhuk
-1 siblings, 0 replies; 42+ messages in thread
From: Ivan Khoronzhuk @ 2014-05-19 10:25 UTC (permalink / raw)
To: dbaryshkov, dwmw2, santosh.shilimkar, robh+dt, pawel.moll,
mark.rutland, ijc+devicetree, galak, grant.likely
Cc: arnd, rdunlap, linux, grygorii.strashko, olof, w-kwok2, sboyd,
devicetree, linux-doc, linux-kernel, linux-arm-kernel,
Ivan Khoronzhuk
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 | 61 ++++++++++++++++++++++
1 file changed, 61 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..d1f6f00
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/keystone-reset.txt
@@ -0,0 +1,61 @@
+* 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
+
+- reg: Contains offset/length value for mux registers.
+
+ reg = <0x23100e4 0x10>,
+ <0x2620328 0x10>;
+
+-reg-names: Contains two ranges "pllregs" and "muxregs".
+ "pllregs" - PLL reset control regs: RSTYPE, RSCTRL,
+ RSCFG, RSISO.
+ "muxregs" - 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.
+
+rstctrl: reset-controller {
+ compatible = "ti,keystone-reset";
+ reg = <0x23100e4 0x10>,
+ <0x2620328 0x10>;
+ reg-names = "pllregs", "muxregs";
+ 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";
+ reg = <0x23100e4 0x10>,
+ <0x2620328 0x10>;
+ reg-names = "pllregs", "muxregs";
+ ti,wdt_list = <0>, <2>;
+ ti,soft-reset;
+};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 42+ messages in thread
* [Patch v3 2/5] Power: reset: add bindings for keystone reset driver
@ 2014-05-19 10:25 ` Ivan Khoronzhuk
0 siblings, 0 replies; 42+ messages in thread
From: Ivan Khoronzhuk @ 2014-05-19 10:25 UTC (permalink / raw)
To: dbaryshkov, dwmw2, santosh.shilimkar, robh+dt, pawel.moll,
mark.rutland, ijc+devicetree, galak, grant.likely
Cc: devicetree, grygorii.strashko, linux, arnd, linux-doc, w-kwok2,
rdunlap, sboyd, linux-kernel, 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 | 61 ++++++++++++++++++++++
1 file changed, 61 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..d1f6f00
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/keystone-reset.txt
@@ -0,0 +1,61 @@
+* 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
+
+- reg: Contains offset/length value for mux registers.
+
+ reg = <0x23100e4 0x10>,
+ <0x2620328 0x10>;
+
+-reg-names: Contains two ranges "pllregs" and "muxregs".
+ "pllregs" - PLL reset control regs: RSTYPE, RSCTRL,
+ RSCFG, RSISO.
+ "muxregs" - 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.
+
+rstctrl: reset-controller {
+ compatible = "ti,keystone-reset";
+ reg = <0x23100e4 0x10>,
+ <0x2620328 0x10>;
+ reg-names = "pllregs", "muxregs";
+ 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";
+ reg = <0x23100e4 0x10>,
+ <0x2620328 0x10>;
+ reg-names = "pllregs", "muxregs";
+ ti,wdt_list = <0>, <2>;
+ ti,soft-reset;
+};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 42+ messages in thread
* [Patch v3 2/5] Power: reset: add bindings for keystone reset driver
@ 2014-05-19 10:25 ` Ivan Khoronzhuk
0 siblings, 0 replies; 42+ messages in thread
From: Ivan Khoronzhuk @ 2014-05-19 10:25 UTC (permalink / raw)
To: 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 | 61 ++++++++++++++++++++++
1 file changed, 61 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..d1f6f00
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/keystone-reset.txt
@@ -0,0 +1,61 @@
+* 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
+
+- reg: Contains offset/length value for mux registers.
+
+ reg = <0x23100e4 0x10>,
+ <0x2620328 0x10>;
+
+-reg-names: Contains two ranges "pllregs" and "muxregs".
+ "pllregs" - PLL reset control regs: RSTYPE, RSCTRL,
+ RSCFG, RSISO.
+ "muxregs" - 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.
+
+rstctrl: reset-controller {
+ compatible = "ti,keystone-reset";
+ reg = <0x23100e4 0x10>,
+ <0x2620328 0x10>;
+ reg-names = "pllregs", "muxregs";
+ 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";
+ reg = <0x23100e4 0x10>,
+ <0x2620328 0x10>;
+ reg-names = "pllregs", "muxregs";
+ ti,wdt_list = <0>, <2>;
+ ti,soft-reset;
+};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 42+ messages in thread
* [Patch v3 3/5] ARM: keystone: remove redundant reset stuff
2014-05-19 10:25 ` Ivan Khoronzhuk
(?)
@ 2014-05-19 10:25 ` Ivan Khoronzhuk
-1 siblings, 0 replies; 42+ messages in thread
From: Ivan Khoronzhuk @ 2014-05-19 10:25 UTC (permalink / raw)
To: dbaryshkov, dwmw2, santosh.shilimkar, robh+dt, pawel.moll,
mark.rutland, ijc+devicetree, galak, grant.likely
Cc: arnd, rdunlap, linux, grygorii.strashko, olof, w-kwok2, sboyd,
devicetree, linux-doc, linux-kernel, linux-arm-kernel,
Ivan Khoronzhuk
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 | 35 -----------------------------------
1 file changed, 35 deletions(-)
diff --git a/arch/arm/mach-keystone/keystone.c b/arch/arm/mach-keystone/keystone.c
index e0b9e1b..c96e2a4 100644
--- a/arch/arm/mach-keystone/keystone.c
+++ b/arch/arm/mach-keystone/keystone.c
@@ -23,24 +23,8 @@
#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 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();
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
@@ -50,24 +34,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,
@@ -75,5 +41,4 @@ DT_MACHINE_START(KEYSTONE, "Keystone")
.smp = smp_ops(keystone_smp_ops),
.init_machine = keystone_init,
.dt_compat = keystone_match,
- .restart = keystone_restart,
MACHINE_END
--
1.8.3.2
^ permalink raw reply related [flat|nested] 42+ messages in thread
* [Patch v3 3/5] ARM: keystone: remove redundant reset stuff
@ 2014-05-19 10:25 ` Ivan Khoronzhuk
0 siblings, 0 replies; 42+ messages in thread
From: Ivan Khoronzhuk @ 2014-05-19 10:25 UTC (permalink / raw)
To: dbaryshkov, dwmw2, santosh.shilimkar, robh+dt, pawel.moll,
mark.rutland, ijc+devicetree, galak, grant.likely
Cc: devicetree, grygorii.strashko, linux, arnd, linux-doc, w-kwok2,
rdunlap, sboyd, linux-kernel, 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 | 35 -----------------------------------
1 file changed, 35 deletions(-)
diff --git a/arch/arm/mach-keystone/keystone.c b/arch/arm/mach-keystone/keystone.c
index e0b9e1b..c96e2a4 100644
--- a/arch/arm/mach-keystone/keystone.c
+++ b/arch/arm/mach-keystone/keystone.c
@@ -23,24 +23,8 @@
#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 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();
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
@@ -50,24 +34,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,
@@ -75,5 +41,4 @@ DT_MACHINE_START(KEYSTONE, "Keystone")
.smp = smp_ops(keystone_smp_ops),
.init_machine = keystone_init,
.dt_compat = keystone_match,
- .restart = keystone_restart,
MACHINE_END
--
1.8.3.2
^ permalink raw reply related [flat|nested] 42+ messages in thread
* [Patch v3 3/5] ARM: keystone: remove redundant reset stuff
@ 2014-05-19 10:25 ` Ivan Khoronzhuk
0 siblings, 0 replies; 42+ messages in thread
From: Ivan Khoronzhuk @ 2014-05-19 10:25 UTC (permalink / raw)
To: 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 | 35 -----------------------------------
1 file changed, 35 deletions(-)
diff --git a/arch/arm/mach-keystone/keystone.c b/arch/arm/mach-keystone/keystone.c
index e0b9e1b..c96e2a4 100644
--- a/arch/arm/mach-keystone/keystone.c
+++ b/arch/arm/mach-keystone/keystone.c
@@ -23,24 +23,8 @@
#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 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();
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
@@ -50,24 +34,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,
@@ -75,5 +41,4 @@ DT_MACHINE_START(KEYSTONE, "Keystone")
.smp = smp_ops(keystone_smp_ops),
.init_machine = keystone_init,
.dt_compat = keystone_match,
- .restart = keystone_restart,
MACHINE_END
--
1.8.3.2
^ permalink raw reply related [flat|nested] 42+ messages in thread
* [Patch v3 4/5] ARM: dts: keystone: update reset node to work with reset driver
2014-05-19 10:25 ` Ivan Khoronzhuk
(?)
@ 2014-05-19 10:25 ` Ivan Khoronzhuk
-1 siblings, 0 replies; 42+ messages in thread
From: Ivan Khoronzhuk @ 2014-05-19 10:25 UTC (permalink / raw)
To: dbaryshkov, dwmw2, santosh.shilimkar, robh+dt, pawel.moll,
mark.rutland, ijc+devicetree, galak, grant.likely
Cc: arnd, rdunlap, linux, grygorii.strashko, olof, w-kwok2, sboyd,
devicetree, linux-doc, linux-kernel, linux-arm-kernel,
Ivan Khoronzhuk
The reset controller registers are part of the PLL Controller MMRs.
According to TRM there are the following registers:
RSTYPE, RSCTRL, RSCFG and RSISO. Currently declared only one of them,
but that is not enough to correctly setup reset properties, so add
whole range of pll registers - pllregs.
Also add range for reset multiplex registers for SoC on the device.
These registers are located in Bootcfg memory space and needed
to setup behaviour after appropriate watchdog is triggered.
Add "ti,wdt_list" option to declare what watchdog are used to reboot
the SoC.
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 90823eb..9d6b850 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -69,7 +69,9 @@
rstctrl: reset-controller {
compatible = "ti,keystone-reset";
- reg = <0x023100e8 4>; /* pll reset control reg */
+ reg = <0x23100e4 0x10>, <0x2620328 0x10>;
+ reg-names = "pllregs", "muxregs";
+ ti,wdt_list = <0>;
};
/include/ "keystone-clocks.dtsi"
--
1.8.3.2
^ permalink raw reply related [flat|nested] 42+ messages in thread
* [Patch v3 4/5] ARM: dts: keystone: update reset node to work with reset driver
@ 2014-05-19 10:25 ` Ivan Khoronzhuk
0 siblings, 0 replies; 42+ messages in thread
From: Ivan Khoronzhuk @ 2014-05-19 10:25 UTC (permalink / raw)
To: dbaryshkov, dwmw2, santosh.shilimkar, robh+dt, pawel.moll,
mark.rutland, ijc+devicetree, galak, grant.likely
Cc: arnd, rdunlap, linux, grygorii.strashko, olof, w-kwok2, sboyd,
devicetree, linux-doc, linux-kernel, linux-arm-kernel,
Ivan Khoronzhuk
The reset controller registers are part of the PLL Controller MMRs.
According to TRM there are the following registers:
RSTYPE, RSCTRL, RSCFG and RSISO. Currently declared only one of them,
but that is not enough to correctly setup reset properties, so add
whole range of pll registers - pllregs.
Also add range for reset multiplex registers for SoC on the device.
These registers are located in Bootcfg memory space and needed
to setup behaviour after appropriate watchdog is triggered.
Add "ti,wdt_list" option to declare what watchdog are used to reboot
the SoC.
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 90823eb..9d6b850 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -69,7 +69,9 @@
rstctrl: reset-controller {
compatible = "ti,keystone-reset";
- reg = <0x023100e8 4>; /* pll reset control reg */
+ reg = <0x23100e4 0x10>, <0x2620328 0x10>;
+ reg-names = "pllregs", "muxregs";
+ ti,wdt_list = <0>;
};
/include/ "keystone-clocks.dtsi"
--
1.8.3.2
^ permalink raw reply related [flat|nested] 42+ messages in thread
* [Patch v3 4/5] ARM: dts: keystone: update reset node to work with reset driver
@ 2014-05-19 10:25 ` Ivan Khoronzhuk
0 siblings, 0 replies; 42+ messages in thread
From: Ivan Khoronzhuk @ 2014-05-19 10:25 UTC (permalink / raw)
To: linux-arm-kernel
The reset controller registers are part of the PLL Controller MMRs.
According to TRM there are the following registers:
RSTYPE, RSCTRL, RSCFG and RSISO. Currently declared only one of them,
but that is not enough to correctly setup reset properties, so add
whole range of pll registers - pllregs.
Also add range for reset multiplex registers for SoC on the device.
These registers are located in Bootcfg memory space and needed
to setup behaviour after appropriate watchdog is triggered.
Add "ti,wdt_list" option to declare what watchdog are used to reboot
the SoC.
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 90823eb..9d6b850 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -69,7 +69,9 @@
rstctrl: reset-controller {
compatible = "ti,keystone-reset";
- reg = <0x023100e8 4>; /* pll reset control reg */
+ reg = <0x23100e4 0x10>, <0x2620328 0x10>;
+ reg-names = "pllregs", "muxregs";
+ ti,wdt_list = <0>;
};
/include/ "keystone-clocks.dtsi"
--
1.8.3.2
^ permalink raw reply related [flat|nested] 42+ messages in thread
* [Patch v3 5/5] ARM: keystone: enable reset driver support
2014-05-19 10:25 ` Ivan Khoronzhuk
(?)
@ 2014-05-19 10:25 ` Ivan Khoronzhuk
-1 siblings, 0 replies; 42+ messages in thread
From: Ivan Khoronzhuk @ 2014-05-19 10:25 UTC (permalink / raw)
To: dbaryshkov, dwmw2, santosh.shilimkar, robh+dt, pawel.moll,
mark.rutland, ijc+devicetree, galak, grant.likely
Cc: arnd, rdunlap, linux, grygorii.strashko, olof, w-kwok2, sboyd,
devicetree, linux-doc, linux-kernel, linux-arm-kernel,
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 ec9a41d..86f02cb 100644
--- a/arch/arm/configs/keystone_defconfig
+++ b/arch/arm/configs/keystone_defconfig
@@ -131,6 +131,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] 42+ messages in thread
* [Patch v3 5/5] ARM: keystone: enable reset driver support
@ 2014-05-19 10:25 ` Ivan Khoronzhuk
0 siblings, 0 replies; 42+ messages in thread
From: Ivan Khoronzhuk @ 2014-05-19 10:25 UTC (permalink / raw)
To: dbaryshkov, dwmw2, santosh.shilimkar, robh+dt, pawel.moll,
mark.rutland, ijc+devicetree, galak, grant.likely
Cc: arnd, rdunlap, linux, grygorii.strashko, olof, w-kwok2, sboyd,
devicetree, linux-doc, linux-kernel, linux-arm-kernel,
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 ec9a41d..86f02cb 100644
--- a/arch/arm/configs/keystone_defconfig
+++ b/arch/arm/configs/keystone_defconfig
@@ -131,6 +131,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] 42+ messages in thread
* [Patch v3 5/5] ARM: keystone: enable reset driver support
@ 2014-05-19 10:25 ` Ivan Khoronzhuk
0 siblings, 0 replies; 42+ messages in thread
From: Ivan Khoronzhuk @ 2014-05-19 10:25 UTC (permalink / raw)
To: linux-arm-kernel
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 ec9a41d..86f02cb 100644
--- a/arch/arm/configs/keystone_defconfig
+++ b/arch/arm/configs/keystone_defconfig
@@ -131,6 +131,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] 42+ messages in thread
* Re: [Patch v3 0/5] Introduce keystone reset driver
2014-05-19 10:25 ` Ivan Khoronzhuk
(?)
@ 2014-05-19 15:07 ` Santosh Shilimkar
-1 siblings, 0 replies; 42+ messages in thread
From: Santosh Shilimkar @ 2014-05-19 15:07 UTC (permalink / raw)
To: dbaryshkov, dwmw2, ijc+devicetree, arnd
Cc: Ivan Khoronzhuk, robh+dt, pawel.moll, mark.rutland, galak,
grant.likely, rdunlap, linux, grygorii.strashko, olof, w-kwok2,
sboyd, devicetree, linux-doc, linux-kernel, linux-arm-kernel
On Monday 19 May 2014 06:25 AM, 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 v3.15-rc5
>
Arnd,
Can I have have your ack/reviewed-by please since you did gave few comments
on previous version.
Dmitry, David W,
Are you ok to get the drivers/power/reset/ related changes merged via arm-soc
tree ? If not, we can split the series accordingly.
Am hoping to get the series merged for v3.16 so do let me know your preference
as early as you can.
> v2..v3
> Power: reset: keystone-reset: introduce keystone reset driver
> - no functional changes, only sanity
> Power: reset: add bindings for keystone reset driver
> - corrected WDT numeration in examples
> - extended description of wdt_list property
>
> v1..v2
> - re basedon on v3.15-rc1 without changes
>
> Ivan Khoronzhuk (5):
> Power: reset: keystone-reset: introduce keystone reset driver
> Power: reset: add bindings for keystone reset driver
> ARM: keystone: remove redundant reset stuff
> ARM: dts: keystone: update reset node to work with reset driver
> ARM: keystone: enable reset driver support
>
> .../bindings/power/reset/keystone-reset.txt | 61 ++++++++
> arch/arm/boot/dts/keystone.dtsi | 4 +-
> arch/arm/configs/keystone_defconfig | 3 +
> arch/arm/mach-keystone/keystone.c | 35 -----
> drivers/power/reset/Kconfig | 7 +
> drivers/power/reset/Makefile | 1 +
> drivers/power/reset/keystone-reset.c | 171 +++++++++++++++++++++
> 7 files changed, 246 insertions(+), 36 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/power/reset/keystone-reset.txt
> create mode 100644 drivers/power/reset/keystone-reset.c
>
Regards,
Santosh
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Patch v3 0/5] Introduce keystone reset driver
@ 2014-05-19 15:07 ` Santosh Shilimkar
0 siblings, 0 replies; 42+ messages in thread
From: Santosh Shilimkar @ 2014-05-19 15:07 UTC (permalink / raw)
To: dbaryshkov, dwmw2, ijc+devicetree, arnd
Cc: Ivan Khoronzhuk, robh+dt, pawel.moll, mark.rutland, galak,
grant.likely, rdunlap, linux, grygorii.strashko, olof, w-kwok2,
sboyd, devicetree, linux-doc, linux-kernel, linux-arm-kernel
On Monday 19 May 2014 06:25 AM, 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 v3.15-rc5
>
Arnd,
Can I have have your ack/reviewed-by please since you did gave few comments
on previous version.
Dmitry, David W,
Are you ok to get the drivers/power/reset/ related changes merged via arm-soc
tree ? If not, we can split the series accordingly.
Am hoping to get the series merged for v3.16 so do let me know your preference
as early as you can.
> v2..v3
> Power: reset: keystone-reset: introduce keystone reset driver
> - no functional changes, only sanity
> Power: reset: add bindings for keystone reset driver
> - corrected WDT numeration in examples
> - extended description of wdt_list property
>
> v1..v2
> - re basedon on v3.15-rc1 without changes
>
> Ivan Khoronzhuk (5):
> Power: reset: keystone-reset: introduce keystone reset driver
> Power: reset: add bindings for keystone reset driver
> ARM: keystone: remove redundant reset stuff
> ARM: dts: keystone: update reset node to work with reset driver
> ARM: keystone: enable reset driver support
>
> .../bindings/power/reset/keystone-reset.txt | 61 ++++++++
> arch/arm/boot/dts/keystone.dtsi | 4 +-
> arch/arm/configs/keystone_defconfig | 3 +
> arch/arm/mach-keystone/keystone.c | 35 -----
> drivers/power/reset/Kconfig | 7 +
> drivers/power/reset/Makefile | 1 +
> drivers/power/reset/keystone-reset.c | 171 +++++++++++++++++++++
> 7 files changed, 246 insertions(+), 36 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/power/reset/keystone-reset.txt
> create mode 100644 drivers/power/reset/keystone-reset.c
>
Regards,
Santosh
^ permalink raw reply [flat|nested] 42+ messages in thread
* [Patch v3 0/5] Introduce keystone reset driver
@ 2014-05-19 15:07 ` Santosh Shilimkar
0 siblings, 0 replies; 42+ messages in thread
From: Santosh Shilimkar @ 2014-05-19 15:07 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 19 May 2014 06:25 AM, 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 v3.15-rc5
>
Arnd,
Can I have have your ack/reviewed-by please since you did gave few comments
on previous version.
Dmitry, David W,
Are you ok to get the drivers/power/reset/ related changes merged via arm-soc
tree ? If not, we can split the series accordingly.
Am hoping to get the series merged for v3.16 so do let me know your preference
as early as you can.
> v2..v3
> Power: reset: keystone-reset: introduce keystone reset driver
> - no functional changes, only sanity
> Power: reset: add bindings for keystone reset driver
> - corrected WDT numeration in examples
> - extended description of wdt_list property
>
> v1..v2
> - re basedon on v3.15-rc1 without changes
>
> Ivan Khoronzhuk (5):
> Power: reset: keystone-reset: introduce keystone reset driver
> Power: reset: add bindings for keystone reset driver
> ARM: keystone: remove redundant reset stuff
> ARM: dts: keystone: update reset node to work with reset driver
> ARM: keystone: enable reset driver support
>
> .../bindings/power/reset/keystone-reset.txt | 61 ++++++++
> arch/arm/boot/dts/keystone.dtsi | 4 +-
> arch/arm/configs/keystone_defconfig | 3 +
> arch/arm/mach-keystone/keystone.c | 35 -----
> drivers/power/reset/Kconfig | 7 +
> drivers/power/reset/Makefile | 1 +
> drivers/power/reset/keystone-reset.c | 171 +++++++++++++++++++++
> 7 files changed, 246 insertions(+), 36 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/power/reset/keystone-reset.txt
> create mode 100644 drivers/power/reset/keystone-reset.c
>
Regards,
Santosh
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Patch v3 0/5] Introduce keystone reset driver
2014-05-19 15:07 ` Santosh Shilimkar
(?)
@ 2014-05-19 17:47 ` Arnd Bergmann
-1 siblings, 0 replies; 42+ messages in thread
From: Arnd Bergmann @ 2014-05-19 17:47 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: dbaryshkov, dwmw2, ijc+devicetree, Ivan Khoronzhuk, robh+dt,
pawel.moll, mark.rutland, galak, grant.likely, rdunlap, linux,
grygorii.strashko, olof, w-kwok2, sboyd, devicetree, linux-doc,
linux-kernel, linux-arm-kernel
On Monday 19 May 2014 11:07:24 Santosh Shilimkar wrote:
> On Monday 19 May 2014 06:25 AM, 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 v3.15-rc5
> >
> Arnd,
> Can I have have your ack/reviewed-by please since you did gave few comments
> on previous version.
Sorry for not getting back to you earlier on this topic.
> On 04/14/2014 09:44 PM, Arnd Bergmann wrote:
> > On Monday 14 April 2014 20:41:20 Ivan Khoronzhuk wrote:
> >> +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.
> >> + The list in format: <0>, <2>;
> >> + Begins from 0 to 3, as keystone can contain up
> >> + to 4 SoC reset watchdogs.
> >
> > This looks like your binding just describes a subset of the
> > watchdog timer registers. If so, don't do a standalone reset
>
> The registers are not a subset of watchdog hardware it's SoC specific future
> controlled by SoC specific registers (bootregs and PLL regs).
>
> For watchog IP setup, the Keystone uses the watchdog driver common with
> other
> SoCs -- davinci_watchdog that is not depend on other SoC settings like
> this driver does.
>
> The Keystone SoCs have separate registers to tune Keystone2 reset
> functionality
> by configuring Reset multiplexer & PLL. And it tunes not only watchdog
> usage.
> The keystone SoC can be rebooted in several ways. By external reset pin,
> by soft and
> by watchdogs. This driver allows software reset or reset by one of the
> watchdogs
> (and other settings) independently on watchdog driver settings. This is
> job of reset driver.
It sounds like you use a syscon area in the reset driver. This is not
uncommon, but it means you should probably have a generic node for
the SoC specific registers that contains all of them at once and
exports them as a regmap using the drivers/mfd/syscon.c driver.
Arnd
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Patch v3 0/5] Introduce keystone reset driver
@ 2014-05-19 17:47 ` Arnd Bergmann
0 siblings, 0 replies; 42+ messages in thread
From: Arnd Bergmann @ 2014-05-19 17:47 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: mark.rutland, devicetree, grygorii.strashko, linux, linux-doc,
pawel.moll, ijc+devicetree, dbaryshkov, rdunlap, sboyd,
linux-kernel, olof, robh+dt, linux-arm-kernel, galak,
grant.likely, Ivan Khoronzhuk, dwmw2, w-kwok2
On Monday 19 May 2014 11:07:24 Santosh Shilimkar wrote:
> On Monday 19 May 2014 06:25 AM, 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 v3.15-rc5
> >
> Arnd,
> Can I have have your ack/reviewed-by please since you did gave few comments
> on previous version.
Sorry for not getting back to you earlier on this topic.
> On 04/14/2014 09:44 PM, Arnd Bergmann wrote:
> > On Monday 14 April 2014 20:41:20 Ivan Khoronzhuk wrote:
> >> +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.
> >> + The list in format: <0>, <2>;
> >> + Begins from 0 to 3, as keystone can contain up
> >> + to 4 SoC reset watchdogs.
> >
> > This looks like your binding just describes a subset of the
> > watchdog timer registers. If so, don't do a standalone reset
>
> The registers are not a subset of watchdog hardware it's SoC specific future
> controlled by SoC specific registers (bootregs and PLL regs).
>
> For watchog IP setup, the Keystone uses the watchdog driver common with
> other
> SoCs -- davinci_watchdog that is not depend on other SoC settings like
> this driver does.
>
> The Keystone SoCs have separate registers to tune Keystone2 reset
> functionality
> by configuring Reset multiplexer & PLL. And it tunes not only watchdog
> usage.
> The keystone SoC can be rebooted in several ways. By external reset pin,
> by soft and
> by watchdogs. This driver allows software reset or reset by one of the
> watchdogs
> (and other settings) independently on watchdog driver settings. This is
> job of reset driver.
It sounds like you use a syscon area in the reset driver. This is not
uncommon, but it means you should probably have a generic node for
the SoC specific registers that contains all of them at once and
exports them as a regmap using the drivers/mfd/syscon.c driver.
Arnd
^ permalink raw reply [flat|nested] 42+ messages in thread
* [Patch v3 0/5] Introduce keystone reset driver
@ 2014-05-19 17:47 ` Arnd Bergmann
0 siblings, 0 replies; 42+ messages in thread
From: Arnd Bergmann @ 2014-05-19 17:47 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 19 May 2014 11:07:24 Santosh Shilimkar wrote:
> On Monday 19 May 2014 06:25 AM, 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 v3.15-rc5
> >
> Arnd,
> Can I have have your ack/reviewed-by please since you did gave few comments
> on previous version.
Sorry for not getting back to you earlier on this topic.
> On 04/14/2014 09:44 PM, Arnd Bergmann wrote:
> > On Monday 14 April 2014 20:41:20 Ivan Khoronzhuk wrote:
> >> +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.
> >> + The list in format: <0>, <2>;
> >> + Begins from 0 to 3, as keystone can contain up
> >> + to 4 SoC reset watchdogs.
> >
> > This looks like your binding just describes a subset of the
> > watchdog timer registers. If so, don't do a standalone reset
>
> The registers are not a subset of watchdog hardware it's SoC specific future
> controlled by SoC specific registers (bootregs and PLL regs).
>
> For watchog IP setup, the Keystone uses the watchdog driver common with
> other
> SoCs -- davinci_watchdog that is not depend on other SoC settings like
> this driver does.
>
> The Keystone SoCs have separate registers to tune Keystone2 reset
> functionality
> by configuring Reset multiplexer & PLL. And it tunes not only watchdog
> usage.
> The keystone SoC can be rebooted in several ways. By external reset pin,
> by soft and
> by watchdogs. This driver allows software reset or reset by one of the
> watchdogs
> (and other settings) independently on watchdog driver settings. This is
> job of reset driver.
It sounds like you use a syscon area in the reset driver. This is not
uncommon, but it means you should probably have a generic node for
the SoC specific registers that contains all of them at once and
exports them as a regmap using the drivers/mfd/syscon.c driver.
Arnd
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Patch v3 0/5] Introduce keystone reset driver
2014-05-19 17:47 ` Arnd Bergmann
(?)
@ 2014-05-20 13:16 ` Ivan Khoronzhuk
-1 siblings, 0 replies; 42+ messages in thread
From: Ivan Khoronzhuk @ 2014-05-20 13:16 UTC (permalink / raw)
To: Arnd Bergmann, Santosh Shilimkar
Cc: dbaryshkov, dwmw2, ijc+devicetree, robh+dt, pawel.moll,
mark.rutland, galak, grant.likely, rdunlap, linux,
grygorii.strashko, olof, w-kwok2, sboyd, devicetree, linux-doc,
linux-kernel, linux-arm-kernel
On 05/19/2014 08:47 PM, Arnd Bergmann wrote:
> On Monday 19 May 2014 11:07:24 Santosh Shilimkar wrote:
>> On Monday 19 May 2014 06:25 AM, 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 v3.15-rc5
>>>
>> Arnd,
>> Can I have have your ack/reviewed-by please since you did gave few comments
>> on previous version.
> Sorry for not getting back to you earlier on this topic.
>
>> On 04/14/2014 09:44 PM, Arnd Bergmann wrote:
>>> On Monday 14 April 2014 20:41:20 Ivan Khoronzhuk wrote:
>>>> +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.
>>>> + The list in format: <0>, <2>;
>>>> + Begins from 0 to 3, as keystone can contain up
>>>> + to 4 SoC reset watchdogs.
>>> This looks like your binding just describes a subset of the
>>> watchdog timer registers. If so, don't do a standalone reset
>> The registers are not a subset of watchdog hardware it's SoC specific future
>> controlled by SoC specific registers (bootregs and PLL regs).
>>
>> For watchog IP setup, the Keystone uses the watchdog driver common with
>> other
>> SoCs -- davinci_watchdog that is not depend on other SoC settings like
>> this driver does.
>>
>> The Keystone SoCs have separate registers to tune Keystone2 reset
>> functionality
>> by configuring Reset multiplexer & PLL. And it tunes not only watchdog
>> usage.
>> The keystone SoC can be rebooted in several ways. By external reset pin,
>> by soft and
>> by watchdogs. This driver allows software reset or reset by one of the
>> watchdogs
>> (and other settings) independently on watchdog driver settings. This is
>> job of reset driver.
> It sounds like you use a syscon area in the reset driver. This is not
> uncommon, but it means you should probably have a generic node for
> the SoC specific registers that contains all of them at once and
> exports them as a regmap using the drivers/mfd/syscon.c driver.
>
> Arnd
Arnd,
Thank for the reply
The reset driver uses two ranges:
- RSTYPE, RSTCTRL,RSTCFG, RSISO (Reset Main PLL Controller)
- RESETMUX8-10 registers
The content of these register ranges are completely used by the reset
driver.
Currently no one on the SoC can access them instead of the reset driver.
Also we don't use syscon/regmap at all - so adding this will be some
overhead.
As I posted previously:
"...configuring Reset multiplexer & PLL. And it tunes not only watchdog
usage..."
Yes, it tunes not only watchdog usage and uses part of registers from
PLL controller,
but all it works with are connected with reset functionality. These
ranges are used only
by reset driver and their purpose is reset functionality.
Maybe in the future some soft can use ranges in question for own tasks,
but it should be
done via reset driver. So as I see there is no reasons to use regmap for
reset driver.
--
Regards,
Ivan Khoronzhuk
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Patch v3 0/5] Introduce keystone reset driver
@ 2014-05-20 13:16 ` Ivan Khoronzhuk
0 siblings, 0 replies; 42+ messages in thread
From: Ivan Khoronzhuk @ 2014-05-20 13:16 UTC (permalink / raw)
To: Arnd Bergmann, Santosh Shilimkar
Cc: dbaryshkov, dwmw2, ijc+devicetree, robh+dt, pawel.moll,
mark.rutland, galak, grant.likely, rdunlap, linux,
grygorii.strashko, olof, w-kwok2, sboyd, devicetree, linux-doc,
linux-kernel, linux-arm-kernel
On 05/19/2014 08:47 PM, Arnd Bergmann wrote:
> On Monday 19 May 2014 11:07:24 Santosh Shilimkar wrote:
>> On Monday 19 May 2014 06:25 AM, 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 v3.15-rc5
>>>
>> Arnd,
>> Can I have have your ack/reviewed-by please since you did gave few comments
>> on previous version.
> Sorry for not getting back to you earlier on this topic.
>
>> On 04/14/2014 09:44 PM, Arnd Bergmann wrote:
>>> On Monday 14 April 2014 20:41:20 Ivan Khoronzhuk wrote:
>>>> +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.
>>>> + The list in format: <0>, <2>;
>>>> + Begins from 0 to 3, as keystone can contain up
>>>> + to 4 SoC reset watchdogs.
>>> This looks like your binding just describes a subset of the
>>> watchdog timer registers. If so, don't do a standalone reset
>> The registers are not a subset of watchdog hardware it's SoC specific future
>> controlled by SoC specific registers (bootregs and PLL regs).
>>
>> For watchog IP setup, the Keystone uses the watchdog driver common with
>> other
>> SoCs -- davinci_watchdog that is not depend on other SoC settings like
>> this driver does.
>>
>> The Keystone SoCs have separate registers to tune Keystone2 reset
>> functionality
>> by configuring Reset multiplexer & PLL. And it tunes not only watchdog
>> usage.
>> The keystone SoC can be rebooted in several ways. By external reset pin,
>> by soft and
>> by watchdogs. This driver allows software reset or reset by one of the
>> watchdogs
>> (and other settings) independently on watchdog driver settings. This is
>> job of reset driver.
> It sounds like you use a syscon area in the reset driver. This is not
> uncommon, but it means you should probably have a generic node for
> the SoC specific registers that contains all of them at once and
> exports them as a regmap using the drivers/mfd/syscon.c driver.
>
> Arnd
Arnd,
Thank for the reply
The reset driver uses two ranges:
- RSTYPE, RSTCTRL,RSTCFG, RSISO (Reset Main PLL Controller)
- RESETMUX8-10 registers
The content of these register ranges are completely used by the reset
driver.
Currently no one on the SoC can access them instead of the reset driver.
Also we don't use syscon/regmap at all - so adding this will be some
overhead.
As I posted previously:
"...configuring Reset multiplexer & PLL. And it tunes not only watchdog
usage..."
Yes, it tunes not only watchdog usage and uses part of registers from
PLL controller,
but all it works with are connected with reset functionality. These
ranges are used only
by reset driver and their purpose is reset functionality.
Maybe in the future some soft can use ranges in question for own tasks,
but it should be
done via reset driver. So as I see there is no reasons to use regmap for
reset driver.
--
Regards,
Ivan Khoronzhuk
^ permalink raw reply [flat|nested] 42+ messages in thread
* [Patch v3 0/5] Introduce keystone reset driver
@ 2014-05-20 13:16 ` Ivan Khoronzhuk
0 siblings, 0 replies; 42+ messages in thread
From: Ivan Khoronzhuk @ 2014-05-20 13:16 UTC (permalink / raw)
To: linux-arm-kernel
On 05/19/2014 08:47 PM, Arnd Bergmann wrote:
> On Monday 19 May 2014 11:07:24 Santosh Shilimkar wrote:
>> On Monday 19 May 2014 06:25 AM, 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 v3.15-rc5
>>>
>> Arnd,
>> Can I have have your ack/reviewed-by please since you did gave few comments
>> on previous version.
> Sorry for not getting back to you earlier on this topic.
>
>> On 04/14/2014 09:44 PM, Arnd Bergmann wrote:
>>> On Monday 14 April 2014 20:41:20 Ivan Khoronzhuk wrote:
>>>> +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.
>>>> + The list in format: <0>, <2>;
>>>> + Begins from 0 to 3, as keystone can contain up
>>>> + to 4 SoC reset watchdogs.
>>> This looks like your binding just describes a subset of the
>>> watchdog timer registers. If so, don't do a standalone reset
>> The registers are not a subset of watchdog hardware it's SoC specific future
>> controlled by SoC specific registers (bootregs and PLL regs).
>>
>> For watchog IP setup, the Keystone uses the watchdog driver common with
>> other
>> SoCs -- davinci_watchdog that is not depend on other SoC settings like
>> this driver does.
>>
>> The Keystone SoCs have separate registers to tune Keystone2 reset
>> functionality
>> by configuring Reset multiplexer & PLL. And it tunes not only watchdog
>> usage.
>> The keystone SoC can be rebooted in several ways. By external reset pin,
>> by soft and
>> by watchdogs. This driver allows software reset or reset by one of the
>> watchdogs
>> (and other settings) independently on watchdog driver settings. This is
>> job of reset driver.
> It sounds like you use a syscon area in the reset driver. This is not
> uncommon, but it means you should probably have a generic node for
> the SoC specific registers that contains all of them at once and
> exports them as a regmap using the drivers/mfd/syscon.c driver.
>
> Arnd
Arnd,
Thank for the reply
The reset driver uses two ranges:
- RSTYPE, RSTCTRL,RSTCFG, RSISO (Reset Main PLL Controller)
- RESETMUX8-10 registers
The content of these register ranges are completely used by the reset
driver.
Currently no one on the SoC can access them instead of the reset driver.
Also we don't use syscon/regmap at all - so adding this will be some
overhead.
As I posted previously:
"...configuring Reset multiplexer & PLL. And it tunes not only watchdog
usage..."
Yes, it tunes not only watchdog usage and uses part of registers from
PLL controller,
but all it works with are connected with reset functionality. These
ranges are used only
by reset driver and their purpose is reset functionality.
Maybe in the future some soft can use ranges in question for own tasks,
but it should be
done via reset driver. So as I see there is no reasons to use regmap for
reset driver.
--
Regards,
Ivan Khoronzhuk
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Patch v3 0/5] Introduce keystone reset driver
@ 2014-05-20 13:44 ` Arnd Bergmann
0 siblings, 0 replies; 42+ messages in thread
From: Arnd Bergmann @ 2014-05-20 13:44 UTC (permalink / raw)
To: Ivan Khoronzhuk
Cc: Santosh Shilimkar, dbaryshkov, dwmw2, ijc+devicetree, robh+dt,
pawel.moll, mark.rutland, galak, grant.likely, rdunlap, linux,
grygorii.strashko, olof, w-kwok2, sboyd, devicetree, linux-doc,
linux-kernel, linux-arm-kernel
On Tuesday 20 May 2014 16:16:08 Ivan Khoronzhuk wrote:
> Thank for the reply
>
> The reset driver uses two ranges:
> - RSTYPE, RSTCTRL,RSTCFG, RSISO (Reset Main PLL Controller)
> - RESETMUX8-10 registers
>
> The content of these register ranges are completely used by the reset
> driver.
> Currently no one on the SoC can access them instead of the reset driver.
> Also we don't use syscon/regmap at all - so adding this will be some
> overhead.
>
> As I posted previously:
> "...configuring Reset multiplexer & PLL. And it tunes not only watchdog
> usage..."
>
> Yes, it tunes not only watchdog usage and uses part of registers from
> PLL controller,
> but all it works with are connected with reset functionality. These
> ranges are used only
> by reset driver and their purpose is reset functionality.
>
> Maybe in the future some soft can use ranges in question for own tasks,
> but it should be
> done via reset driver. So as I see there is no reasons to use regmap for
> reset driver.
You should not look at these registers in isolation, they are part of
some register area that has other functions as well and that you should
at least represent correctly in DT.
When I see something like
+ reg = <0x23100e4 0x10>,
+ <0x2620328 0x10>;
I am certain that there are other things between 0x2310000 and 0x23100e3, and
probably after 0x23100f4 as well. There must be some data sheet that
gives this register range a proper name, so put that into DT rather than
making up some arbitrary stuff that happens to match how today's kernel
driver needs it.
Arnd
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Patch v3 0/5] Introduce keystone reset driver
@ 2014-05-20 13:44 ` Arnd Bergmann
0 siblings, 0 replies; 42+ messages in thread
From: Arnd Bergmann @ 2014-05-20 13:44 UTC (permalink / raw)
To: Ivan Khoronzhuk
Cc: Santosh Shilimkar, dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, pawel.moll-5wv7dgnIgG8,
mark.rutland-5wv7dgnIgG8, 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
On Tuesday 20 May 2014 16:16:08 Ivan Khoronzhuk wrote:
> Thank for the reply
>
> The reset driver uses two ranges:
> - RSTYPE, RSTCTRL,RSTCFG, RSISO (Reset Main PLL Controller)
> - RESETMUX8-10 registers
>
> The content of these register ranges are completely used by the reset
> driver.
> Currently no one on the SoC can access them instead of the reset driver.
> Also we don't use syscon/regmap at all - so adding this will be some
> overhead.
>
> As I posted previously:
> "...configuring Reset multiplexer & PLL. And it tunes not only watchdog
> usage..."
>
> Yes, it tunes not only watchdog usage and uses part of registers from
> PLL controller,
> but all it works with are connected with reset functionality. These
> ranges are used only
> by reset driver and their purpose is reset functionality.
>
> Maybe in the future some soft can use ranges in question for own tasks,
> but it should be
> done via reset driver. So as I see there is no reasons to use regmap for
> reset driver.
You should not look at these registers in isolation, they are part of
some register area that has other functions as well and that you should
at least represent correctly in DT.
When I see something like
+ reg = <0x23100e4 0x10>,
+ <0x2620328 0x10>;
I am certain that there are other things between 0x2310000 and 0x23100e3, and
probably after 0x23100f4 as well. There must be some data sheet that
gives this register range a proper name, so put that into DT rather than
making up some arbitrary stuff that happens to match how today's kernel
driver needs it.
Arnd
--
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] 42+ messages in thread
* [Patch v3 0/5] Introduce keystone reset driver
@ 2014-05-20 13:44 ` Arnd Bergmann
0 siblings, 0 replies; 42+ messages in thread
From: Arnd Bergmann @ 2014-05-20 13:44 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 20 May 2014 16:16:08 Ivan Khoronzhuk wrote:
> Thank for the reply
>
> The reset driver uses two ranges:
> - RSTYPE, RSTCTRL,RSTCFG, RSISO (Reset Main PLL Controller)
> - RESETMUX8-10 registers
>
> The content of these register ranges are completely used by the reset
> driver.
> Currently no one on the SoC can access them instead of the reset driver.
> Also we don't use syscon/regmap at all - so adding this will be some
> overhead.
>
> As I posted previously:
> "...configuring Reset multiplexer & PLL. And it tunes not only watchdog
> usage..."
>
> Yes, it tunes not only watchdog usage and uses part of registers from
> PLL controller,
> but all it works with are connected with reset functionality. These
> ranges are used only
> by reset driver and their purpose is reset functionality.
>
> Maybe in the future some soft can use ranges in question for own tasks,
> but it should be
> done via reset driver. So as I see there is no reasons to use regmap for
> reset driver.
You should not look at these registers in isolation, they are part of
some register area that has other functions as well and that you should
at least represent correctly in DT.
When I see something like
+ reg = <0x23100e4 0x10>,
+ <0x2620328 0x10>;
I am certain that there are other things between 0x2310000 and 0x23100e3, and
probably after 0x23100f4 as well. There must be some data sheet that
gives this register range a proper name, so put that into DT rather than
making up some arbitrary stuff that happens to match how today's kernel
driver needs it.
Arnd
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Patch v3 0/5] Introduce keystone reset driver
2014-05-20 13:44 ` Arnd Bergmann
(?)
@ 2014-05-20 13:49 ` Santosh Shilimkar
-1 siblings, 0 replies; 42+ messages in thread
From: Santosh Shilimkar @ 2014-05-20 13:49 UTC (permalink / raw)
To: Arnd Bergmann, Ivan Khoronzhuk
Cc: dbaryshkov, dwmw2, ijc+devicetree, robh+dt, pawel.moll,
mark.rutland, galak, grant.likely, rdunlap, linux,
grygorii.strashko, olof, w-kwok2, sboyd, devicetree, linux-doc,
linux-kernel, linux-arm-kernel
On Tuesday 20 May 2014 09:44 AM, Arnd Bergmann wrote:
> On Tuesday 20 May 2014 16:16:08 Ivan Khoronzhuk wrote:
>> Thank for the reply
>>
>> The reset driver uses two ranges:
>> - RSTYPE, RSTCTRL,RSTCFG, RSISO (Reset Main PLL Controller)
>> - RESETMUX8-10 registers
>>
>> The content of these register ranges are completely used by the reset
>> driver.
>> Currently no one on the SoC can access them instead of the reset driver.
>> Also we don't use syscon/regmap at all - so adding this will be some
>> overhead.
>>
>> As I posted previously:
>> "...configuring Reset multiplexer & PLL. And it tunes not only watchdog
>> usage..."
>>
>> Yes, it tunes not only watchdog usage and uses part of registers from
>> PLL controller,
>> but all it works with are connected with reset functionality. These
>> ranges are used only
>> by reset driver and their purpose is reset functionality.
>>
>> Maybe in the future some soft can use ranges in question for own tasks,
>> but it should be
>> done via reset driver. So as I see there is no reasons to use regmap for
>> reset driver.
>
> You should not look at these registers in isolation, they are part of
> some register area that has other functions as well and that you should
> at least represent correctly in DT.
>
> When I see something like
>
> + reg = <0x23100e4 0x10>,
> + <0x2620328 0x10>;
>
> I am certain that there are other things between 0x2310000 and 0x23100e3, and
> probably after 0x23100f4 as well. There must be some data sheet that
> gives this register range a proper name, so put that into DT rather than
> making up some arbitrary stuff that happens to match how today's kernel
> driver needs it.
>
Even though there are no other users, I think you have a valid point about
DT representing the hardware layout in the correct form.
Regards,
Santosh
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Patch v3 0/5] Introduce keystone reset driver
@ 2014-05-20 13:49 ` Santosh Shilimkar
0 siblings, 0 replies; 42+ messages in thread
From: Santosh Shilimkar @ 2014-05-20 13:49 UTC (permalink / raw)
To: Arnd Bergmann, Ivan Khoronzhuk
Cc: dbaryshkov, dwmw2, ijc+devicetree, robh+dt, pawel.moll,
mark.rutland, galak, grant.likely, rdunlap, linux,
grygorii.strashko, olof, w-kwok2, sboyd, devicetree, linux-doc,
linux-kernel, linux-arm-kernel
On Tuesday 20 May 2014 09:44 AM, Arnd Bergmann wrote:
> On Tuesday 20 May 2014 16:16:08 Ivan Khoronzhuk wrote:
>> Thank for the reply
>>
>> The reset driver uses two ranges:
>> - RSTYPE, RSTCTRL,RSTCFG, RSISO (Reset Main PLL Controller)
>> - RESETMUX8-10 registers
>>
>> The content of these register ranges are completely used by the reset
>> driver.
>> Currently no one on the SoC can access them instead of the reset driver.
>> Also we don't use syscon/regmap at all - so adding this will be some
>> overhead.
>>
>> As I posted previously:
>> "...configuring Reset multiplexer & PLL. And it tunes not only watchdog
>> usage..."
>>
>> Yes, it tunes not only watchdog usage and uses part of registers from
>> PLL controller,
>> but all it works with are connected with reset functionality. These
>> ranges are used only
>> by reset driver and their purpose is reset functionality.
>>
>> Maybe in the future some soft can use ranges in question for own tasks,
>> but it should be
>> done via reset driver. So as I see there is no reasons to use regmap for
>> reset driver.
>
> You should not look at these registers in isolation, they are part of
> some register area that has other functions as well and that you should
> at least represent correctly in DT.
>
> When I see something like
>
> + reg = <0x23100e4 0x10>,
> + <0x2620328 0x10>;
>
> I am certain that there are other things between 0x2310000 and 0x23100e3, and
> probably after 0x23100f4 as well. There must be some data sheet that
> gives this register range a proper name, so put that into DT rather than
> making up some arbitrary stuff that happens to match how today's kernel
> driver needs it.
>
Even though there are no other users, I think you have a valid point about
DT representing the hardware layout in the correct form.
Regards,
Santosh
^ permalink raw reply [flat|nested] 42+ messages in thread
* [Patch v3 0/5] Introduce keystone reset driver
@ 2014-05-20 13:49 ` Santosh Shilimkar
0 siblings, 0 replies; 42+ messages in thread
From: Santosh Shilimkar @ 2014-05-20 13:49 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 20 May 2014 09:44 AM, Arnd Bergmann wrote:
> On Tuesday 20 May 2014 16:16:08 Ivan Khoronzhuk wrote:
>> Thank for the reply
>>
>> The reset driver uses two ranges:
>> - RSTYPE, RSTCTRL,RSTCFG, RSISO (Reset Main PLL Controller)
>> - RESETMUX8-10 registers
>>
>> The content of these register ranges are completely used by the reset
>> driver.
>> Currently no one on the SoC can access them instead of the reset driver.
>> Also we don't use syscon/regmap at all - so adding this will be some
>> overhead.
>>
>> As I posted previously:
>> "...configuring Reset multiplexer & PLL. And it tunes not only watchdog
>> usage..."
>>
>> Yes, it tunes not only watchdog usage and uses part of registers from
>> PLL controller,
>> but all it works with are connected with reset functionality. These
>> ranges are used only
>> by reset driver and their purpose is reset functionality.
>>
>> Maybe in the future some soft can use ranges in question for own tasks,
>> but it should be
>> done via reset driver. So as I see there is no reasons to use regmap for
>> reset driver.
>
> You should not look at these registers in isolation, they are part of
> some register area that has other functions as well and that you should
> at least represent correctly in DT.
>
> When I see something like
>
> + reg = <0x23100e4 0x10>,
> + <0x2620328 0x10>;
>
> I am certain that there are other things between 0x2310000 and 0x23100e3, and
> probably after 0x23100f4 as well. There must be some data sheet that
> gives this register range a proper name, so put that into DT rather than
> making up some arbitrary stuff that happens to match how today's kernel
> driver needs it.
>
Even though there are no other users, I think you have a valid point about
DT representing the hardware layout in the correct form.
Regards,
Santosh
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Patch v3 0/5] Introduce keystone reset driver
2014-05-20 13:49 ` Santosh Shilimkar
(?)
@ 2014-05-20 18:35 ` Ivan Khoronzhuk
-1 siblings, 0 replies; 42+ messages in thread
From: Ivan Khoronzhuk @ 2014-05-20 18:35 UTC (permalink / raw)
To: Santosh Shilimkar, Arnd Bergmann
Cc: dbaryshkov, dwmw2, ijc+devicetree, robh+dt, pawel.moll,
mark.rutland, galak, grant.likely, rdunlap, linux,
grygorii.strashko, olof, w-kwok2, sboyd, devicetree, linux-doc,
linux-kernel, linux-arm-kernel
On 05/20/2014 04:49 PM, Santosh Shilimkar wrote:
> On Tuesday 20 May 2014 09:44 AM, Arnd Bergmann wrote:
>> On Tuesday 20 May 2014 16:16:08 Ivan Khoronzhuk wrote:
>>> Thank for the reply
>>>
>>> The reset driver uses two ranges:
>>> - RSTYPE, RSTCTRL,RSTCFG, RSISO (Reset Main PLL Controller)
>>> - RESETMUX8-10 registers
>>>
>>> The content of these register ranges are completely used by the reset
>>> driver.
>>> Currently no one on the SoC can access them instead of the reset driver.
>>> Also we don't use syscon/regmap at all - so adding this will be some
>>> overhead.
>>>
>>> As I posted previously:
>>> "...configuring Reset multiplexer & PLL. And it tunes not only watchdog
>>> usage..."
>>>
>>> Yes, it tunes not only watchdog usage and uses part of registers from
>>> PLL controller,
>>> but all it works with are connected with reset functionality. These
>>> ranges are used only
>>> by reset driver and their purpose is reset functionality.
>>>
>>> Maybe in the future some soft can use ranges in question for own tasks,
>>> but it should be
>>> done via reset driver. So as I see there is no reasons to use regmap for
>>> reset driver.
>> You should not look at these registers in isolation, they are part of
>> some register area that has other functions as well and that you should
>> at least represent correctly in DT.
>>
>> When I see something like
>>
>> + reg = <0x23100e4 0x10>,
>> + <0x2620328 0x10>;
>>
>> I am certain that there are other things between 0x2310000 and 0x23100e3, and
>> probably after 0x23100f4 as well. There must be some data sheet that
>> gives this register range a proper name, so put that into DT rather than
>> making up some arbitrary stuff that happens to match how today's kernel
>> driver needs it.
>>
> Even though there are no other users, I think you have a valid point about
> DT representing the hardware layout in the correct form.
>
> Regards,
> Santosh
>
Thank for the note.
Ok.
Memory map:
[00 02310000 - 00 023101FF] size=512 PLL Controller
[00 02620000 - 00 02620FFF] size=4K device state control registers
I'll define in DT two new syscon compatible nodes like:
pllctrl: pll_controller {
compatible = "syscon";
reg = <0x2310000 0x200>;
};
devctrl: device_state_control {
compatible = "syscon";
reg = <0x2620000 0x1000>;
};
then correct reset-controller node like:
rstctrl: reset-controller {
compatible = "ti,keystone-reset";
reg = <0xE4 0x10>, <0x328 0x10>;
reg-names = "pllregs", "muxregs";
syscon1 = <&pllctrl>;
syscon2 = <&devctrl>;
ti,wdt_list = <0>;
};
And correct reset-controller code to get regmap by phandle,
then access registers by regmap.
Also I'll post two separate patches that add syscon nodes in question.
--
Regards,
Ivan Khoronzhuk
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Patch v3 0/5] Introduce keystone reset driver
@ 2014-05-20 18:35 ` Ivan Khoronzhuk
0 siblings, 0 replies; 42+ messages in thread
From: Ivan Khoronzhuk @ 2014-05-20 18:35 UTC (permalink / raw)
To: Santosh Shilimkar, Arnd Bergmann
Cc: dbaryshkov, dwmw2, ijc+devicetree, robh+dt, pawel.moll,
mark.rutland, galak, grant.likely, rdunlap, linux,
grygorii.strashko, olof, w-kwok2, sboyd, devicetree, linux-doc,
linux-kernel, linux-arm-kernel
On 05/20/2014 04:49 PM, Santosh Shilimkar wrote:
> On Tuesday 20 May 2014 09:44 AM, Arnd Bergmann wrote:
>> On Tuesday 20 May 2014 16:16:08 Ivan Khoronzhuk wrote:
>>> Thank for the reply
>>>
>>> The reset driver uses two ranges:
>>> - RSTYPE, RSTCTRL,RSTCFG, RSISO (Reset Main PLL Controller)
>>> - RESETMUX8-10 registers
>>>
>>> The content of these register ranges are completely used by the reset
>>> driver.
>>> Currently no one on the SoC can access them instead of the reset driver.
>>> Also we don't use syscon/regmap at all - so adding this will be some
>>> overhead.
>>>
>>> As I posted previously:
>>> "...configuring Reset multiplexer & PLL. And it tunes not only watchdog
>>> usage..."
>>>
>>> Yes, it tunes not only watchdog usage and uses part of registers from
>>> PLL controller,
>>> but all it works with are connected with reset functionality. These
>>> ranges are used only
>>> by reset driver and their purpose is reset functionality.
>>>
>>> Maybe in the future some soft can use ranges in question for own tasks,
>>> but it should be
>>> done via reset driver. So as I see there is no reasons to use regmap for
>>> reset driver.
>> You should not look at these registers in isolation, they are part of
>> some register area that has other functions as well and that you should
>> at least represent correctly in DT.
>>
>> When I see something like
>>
>> + reg = <0x23100e4 0x10>,
>> + <0x2620328 0x10>;
>>
>> I am certain that there are other things between 0x2310000 and 0x23100e3, and
>> probably after 0x23100f4 as well. There must be some data sheet that
>> gives this register range a proper name, so put that into DT rather than
>> making up some arbitrary stuff that happens to match how today's kernel
>> driver needs it.
>>
> Even though there are no other users, I think you have a valid point about
> DT representing the hardware layout in the correct form.
>
> Regards,
> Santosh
>
Thank for the note.
Ok.
Memory map:
[00 02310000 - 00 023101FF] size=512 PLL Controller
[00 02620000 - 00 02620FFF] size=4K device state control registers
I'll define in DT two new syscon compatible nodes like:
pllctrl: pll_controller {
compatible = "syscon";
reg = <0x2310000 0x200>;
};
devctrl: device_state_control {
compatible = "syscon";
reg = <0x2620000 0x1000>;
};
then correct reset-controller node like:
rstctrl: reset-controller {
compatible = "ti,keystone-reset";
reg = <0xE4 0x10>, <0x328 0x10>;
reg-names = "pllregs", "muxregs";
syscon1 = <&pllctrl>;
syscon2 = <&devctrl>;
ti,wdt_list = <0>;
};
And correct reset-controller code to get regmap by phandle,
then access registers by regmap.
Also I'll post two separate patches that add syscon nodes in question.
--
Regards,
Ivan Khoronzhuk
^ permalink raw reply [flat|nested] 42+ messages in thread
* [Patch v3 0/5] Introduce keystone reset driver
@ 2014-05-20 18:35 ` Ivan Khoronzhuk
0 siblings, 0 replies; 42+ messages in thread
From: Ivan Khoronzhuk @ 2014-05-20 18:35 UTC (permalink / raw)
To: linux-arm-kernel
On 05/20/2014 04:49 PM, Santosh Shilimkar wrote:
> On Tuesday 20 May 2014 09:44 AM, Arnd Bergmann wrote:
>> On Tuesday 20 May 2014 16:16:08 Ivan Khoronzhuk wrote:
>>> Thank for the reply
>>>
>>> The reset driver uses two ranges:
>>> - RSTYPE, RSTCTRL,RSTCFG, RSISO (Reset Main PLL Controller)
>>> - RESETMUX8-10 registers
>>>
>>> The content of these register ranges are completely used by the reset
>>> driver.
>>> Currently no one on the SoC can access them instead of the reset driver.
>>> Also we don't use syscon/regmap at all - so adding this will be some
>>> overhead.
>>>
>>> As I posted previously:
>>> "...configuring Reset multiplexer & PLL. And it tunes not only watchdog
>>> usage..."
>>>
>>> Yes, it tunes not only watchdog usage and uses part of registers from
>>> PLL controller,
>>> but all it works with are connected with reset functionality. These
>>> ranges are used only
>>> by reset driver and their purpose is reset functionality.
>>>
>>> Maybe in the future some soft can use ranges in question for own tasks,
>>> but it should be
>>> done via reset driver. So as I see there is no reasons to use regmap for
>>> reset driver.
>> You should not look at these registers in isolation, they are part of
>> some register area that has other functions as well and that you should
>> at least represent correctly in DT.
>>
>> When I see something like
>>
>> + reg = <0x23100e4 0x10>,
>> + <0x2620328 0x10>;
>>
>> I am certain that there are other things between 0x2310000 and 0x23100e3, and
>> probably after 0x23100f4 as well. There must be some data sheet that
>> gives this register range a proper name, so put that into DT rather than
>> making up some arbitrary stuff that happens to match how today's kernel
>> driver needs it.
>>
> Even though there are no other users, I think you have a valid point about
> DT representing the hardware layout in the correct form.
>
> Regards,
> Santosh
>
Thank for the note.
Ok.
Memory map:
[00 02310000 - 00 023101FF] size=512 PLL Controller
[00 02620000 - 00 02620FFF] size=4K device state control registers
I'll define in DT two new syscon compatible nodes like:
pllctrl: pll_controller {
compatible = "syscon";
reg = <0x2310000 0x200>;
};
devctrl: device_state_control {
compatible = "syscon";
reg = <0x2620000 0x1000>;
};
then correct reset-controller node like:
rstctrl: reset-controller {
compatible = "ti,keystone-reset";
reg = <0xE4 0x10>, <0x328 0x10>;
reg-names = "pllregs", "muxregs";
syscon1 = <&pllctrl>;
syscon2 = <&devctrl>;
ti,wdt_list = <0>;
};
And correct reset-controller code to get regmap by phandle,
then access registers by regmap.
Also I'll post two separate patches that add syscon nodes in question.
--
Regards,
Ivan Khoronzhuk
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Patch v3 0/5] Introduce keystone reset driver
@ 2014-05-20 19:27 ` Arnd Bergmann
0 siblings, 0 replies; 42+ messages in thread
From: Arnd Bergmann @ 2014-05-20 19:27 UTC (permalink / raw)
To: Ivan Khoronzhuk
Cc: Santosh Shilimkar, dbaryshkov, dwmw2, ijc+devicetree, robh+dt,
pawel.moll, mark.rutland, galak, grant.likely, rdunlap, linux,
grygorii.strashko, olof, w-kwok2, sboyd, devicetree, linux-doc,
linux-kernel, linux-arm-kernel
On Tuesday 20 May 2014 21:35:23 Ivan Khoronzhuk wrote:
> Thank for the note.
>
> Ok.
>
> Memory map:
> [00 02310000 - 00 023101FF] size=512 PLL Controller
> [00 02620000 - 00 02620FFF] size=4K device state control registers
>
> I'll define in DT two new syscon compatible nodes like:
>
> pllctrl: pll_controller {
> compatible = "syscon";
> reg = <0x2310000 0x200>;
> };
>
> devctrl: device_state_control {
> compatible = "syscon";
> reg = <0x2620000 0x1000>;
> };
Please add a well-defined compatible-string in addition to "syscon" as
well.
> then correct reset-controller node like:
>
> rstctrl: reset-controller {
> compatible = "ti,keystone-reset";
> reg = <0xE4 0x10>, <0x328 0x10>;
> reg-names = "pllregs", "muxregs";
> syscon1 = <&pllctrl>;
> syscon2 = <&devctrl>;
> ti,wdt_list = <0>;
> };
You can't really use the "reg" property to refer to syscon
registers, but you can make up your own property for that,
or put the register numbers into the syscon1/2 properties,
or just hardcode the offsets in the driver.
> And correct reset-controller code to get regmap by phandle,
> then access registers by regmap.
>
> Also I'll post two separate patches that add syscon nodes in question.
Sounds good, thanks!
Arnd
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Patch v3 0/5] Introduce keystone reset driver
@ 2014-05-20 19:27 ` Arnd Bergmann
0 siblings, 0 replies; 42+ messages in thread
From: Arnd Bergmann @ 2014-05-20 19:27 UTC (permalink / raw)
To: Ivan Khoronzhuk
Cc: Santosh Shilimkar, dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, pawel.moll-5wv7dgnIgG8,
mark.rutland-5wv7dgnIgG8, 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
On Tuesday 20 May 2014 21:35:23 Ivan Khoronzhuk wrote:
> Thank for the note.
>
> Ok.
>
> Memory map:
> [00 02310000 - 00 023101FF] size=512 PLL Controller
> [00 02620000 - 00 02620FFF] size=4K device state control registers
>
> I'll define in DT two new syscon compatible nodes like:
>
> pllctrl: pll_controller {
> compatible = "syscon";
> reg = <0x2310000 0x200>;
> };
>
> devctrl: device_state_control {
> compatible = "syscon";
> reg = <0x2620000 0x1000>;
> };
Please add a well-defined compatible-string in addition to "syscon" as
well.
> then correct reset-controller node like:
>
> rstctrl: reset-controller {
> compatible = "ti,keystone-reset";
> reg = <0xE4 0x10>, <0x328 0x10>;
> reg-names = "pllregs", "muxregs";
> syscon1 = <&pllctrl>;
> syscon2 = <&devctrl>;
> ti,wdt_list = <0>;
> };
You can't really use the "reg" property to refer to syscon
registers, but you can make up your own property for that,
or put the register numbers into the syscon1/2 properties,
or just hardcode the offsets in the driver.
> And correct reset-controller code to get regmap by phandle,
> then access registers by regmap.
>
> Also I'll post two separate patches that add syscon nodes in question.
Sounds good, thanks!
Arnd
--
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] 42+ messages in thread
* [Patch v3 0/5] Introduce keystone reset driver
@ 2014-05-20 19:27 ` Arnd Bergmann
0 siblings, 0 replies; 42+ messages in thread
From: Arnd Bergmann @ 2014-05-20 19:27 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 20 May 2014 21:35:23 Ivan Khoronzhuk wrote:
> Thank for the note.
>
> Ok.
>
> Memory map:
> [00 02310000 - 00 023101FF] size=512 PLL Controller
> [00 02620000 - 00 02620FFF] size=4K device state control registers
>
> I'll define in DT two new syscon compatible nodes like:
>
> pllctrl: pll_controller {
> compatible = "syscon";
> reg = <0x2310000 0x200>;
> };
>
> devctrl: device_state_control {
> compatible = "syscon";
> reg = <0x2620000 0x1000>;
> };
Please add a well-defined compatible-string in addition to "syscon" as
well.
> then correct reset-controller node like:
>
> rstctrl: reset-controller {
> compatible = "ti,keystone-reset";
> reg = <0xE4 0x10>, <0x328 0x10>;
> reg-names = "pllregs", "muxregs";
> syscon1 = <&pllctrl>;
> syscon2 = <&devctrl>;
> ti,wdt_list = <0>;
> };
You can't really use the "reg" property to refer to syscon
registers, but you can make up your own property for that,
or put the register numbers into the syscon1/2 properties,
or just hardcode the offsets in the driver.
> And correct reset-controller code to get regmap by phandle,
> then access registers by regmap.
>
> Also I'll post two separate patches that add syscon nodes in question.
Sounds good, thanks!
Arnd
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Patch v3 0/5] Introduce keystone reset driver
2014-05-20 19:27 ` Arnd Bergmann
(?)
@ 2014-05-21 14:28 ` Ivan Khoronzhuk
-1 siblings, 0 replies; 42+ messages in thread
From: Ivan Khoronzhuk @ 2014-05-21 14:28 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Santosh Shilimkar, dbaryshkov, dwmw2, ijc+devicetree, robh+dt,
pawel.moll, mark.rutland, galak, grant.likely, rdunlap, linux,
grygorii.strashko, olof, w-kwok2, sboyd, devicetree, linux-doc,
linux-kernel, linux-arm-kernel
On 05/20/2014 10:27 PM, Arnd Bergmann wrote:
> On Tuesday 20 May 2014 21:35:23 Ivan Khoronzhuk wrote:
>> Thank for the note.
>>
>> Ok.
>>
>> Memory map:
>> [00 02310000 - 00 023101FF] size=512 PLL Controller
>> [00 02620000 - 00 02620FFF] size=4K device state control registers
>>
>> I'll define in DT two new syscon compatible nodes like:
>>
>> pllctrl: pll_controller {
>> compatible = "syscon";
>> reg = <0x2310000 0x200>;
>> };
>>
>> devctrl: device_state_control {
>> compatible = "syscon";
>> reg = <0x2620000 0x1000>;
>> };
> Please add a well-defined compatible-string in addition to "syscon" as
> well.
>
>> then correct reset-controller node like:
>>
>> rstctrl: reset-controller {
>> compatible = "ti,keystone-reset";
>> reg = <0xE4 0x10>, <0x328 0x10>;
>> reg-names = "pllregs", "muxregs";
>> syscon1 = <&pllctrl>;
>> syscon2 = <&devctrl>;
>> ti,wdt_list = <0>;
>> };
> You can't really use the "reg" property to refer to syscon
> registers, but you can make up your own property for that,
> or put the register numbers into the syscon1/2 properties,
> or just hardcode the offsets in the driver.
>
>> And correct reset-controller code to get regmap by phandle,
>> then access registers by regmap.
>>
>> Also I'll post two separate patches that add syscon nodes in question.
> Sounds good, thanks!
>
> Arnd
Arnd,
I've sent an updated patch series v4 with your notes applied.
Could you please take a glance on it.
--
Regards,
Ivan Khoronzhuk
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Patch v3 0/5] Introduce keystone reset driver
@ 2014-05-21 14:28 ` Ivan Khoronzhuk
0 siblings, 0 replies; 42+ messages in thread
From: Ivan Khoronzhuk @ 2014-05-21 14:28 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Santosh Shilimkar, dbaryshkov, dwmw2, ijc+devicetree, robh+dt,
pawel.moll, mark.rutland, galak, grant.likely, rdunlap, linux,
grygorii.strashko, olof, w-kwok2, sboyd, devicetree, linux-doc,
linux-kernel, linux-arm-kernel
On 05/20/2014 10:27 PM, Arnd Bergmann wrote:
> On Tuesday 20 May 2014 21:35:23 Ivan Khoronzhuk wrote:
>> Thank for the note.
>>
>> Ok.
>>
>> Memory map:
>> [00 02310000 - 00 023101FF] size=512 PLL Controller
>> [00 02620000 - 00 02620FFF] size=4K device state control registers
>>
>> I'll define in DT two new syscon compatible nodes like:
>>
>> pllctrl: pll_controller {
>> compatible = "syscon";
>> reg = <0x2310000 0x200>;
>> };
>>
>> devctrl: device_state_control {
>> compatible = "syscon";
>> reg = <0x2620000 0x1000>;
>> };
> Please add a well-defined compatible-string in addition to "syscon" as
> well.
>
>> then correct reset-controller node like:
>>
>> rstctrl: reset-controller {
>> compatible = "ti,keystone-reset";
>> reg = <0xE4 0x10>, <0x328 0x10>;
>> reg-names = "pllregs", "muxregs";
>> syscon1 = <&pllctrl>;
>> syscon2 = <&devctrl>;
>> ti,wdt_list = <0>;
>> };
> You can't really use the "reg" property to refer to syscon
> registers, but you can make up your own property for that,
> or put the register numbers into the syscon1/2 properties,
> or just hardcode the offsets in the driver.
>
>> And correct reset-controller code to get regmap by phandle,
>> then access registers by regmap.
>>
>> Also I'll post two separate patches that add syscon nodes in question.
> Sounds good, thanks!
>
> Arnd
Arnd,
I've sent an updated patch series v4 with your notes applied.
Could you please take a glance on it.
--
Regards,
Ivan Khoronzhuk
^ permalink raw reply [flat|nested] 42+ messages in thread
* [Patch v3 0/5] Introduce keystone reset driver
@ 2014-05-21 14:28 ` Ivan Khoronzhuk
0 siblings, 0 replies; 42+ messages in thread
From: Ivan Khoronzhuk @ 2014-05-21 14:28 UTC (permalink / raw)
To: linux-arm-kernel
On 05/20/2014 10:27 PM, Arnd Bergmann wrote:
> On Tuesday 20 May 2014 21:35:23 Ivan Khoronzhuk wrote:
>> Thank for the note.
>>
>> Ok.
>>
>> Memory map:
>> [00 02310000 - 00 023101FF] size=512 PLL Controller
>> [00 02620000 - 00 02620FFF] size=4K device state control registers
>>
>> I'll define in DT two new syscon compatible nodes like:
>>
>> pllctrl: pll_controller {
>> compatible = "syscon";
>> reg = <0x2310000 0x200>;
>> };
>>
>> devctrl: device_state_control {
>> compatible = "syscon";
>> reg = <0x2620000 0x1000>;
>> };
> Please add a well-defined compatible-string in addition to "syscon" as
> well.
>
>> then correct reset-controller node like:
>>
>> rstctrl: reset-controller {
>> compatible = "ti,keystone-reset";
>> reg = <0xE4 0x10>, <0x328 0x10>;
>> reg-names = "pllregs", "muxregs";
>> syscon1 = <&pllctrl>;
>> syscon2 = <&devctrl>;
>> ti,wdt_list = <0>;
>> };
> You can't really use the "reg" property to refer to syscon
> registers, but you can make up your own property for that,
> or put the register numbers into the syscon1/2 properties,
> or just hardcode the offsets in the driver.
>
>> And correct reset-controller code to get regmap by phandle,
>> then access registers by regmap.
>>
>> Also I'll post two separate patches that add syscon nodes in question.
> Sounds good, thanks!
>
> Arnd
Arnd,
I've sent an updated patch series v4 with your notes applied.
Could you please take a glance on it.
--
Regards,
Ivan Khoronzhuk
^ permalink raw reply [flat|nested] 42+ messages in thread
end of thread, other threads:[~2014-05-21 14:29 UTC | newest]
Thread overview: 42+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-05-19 10:25 [Patch v3 0/5] Introduce keystone reset driver Ivan Khoronzhuk
2014-05-19 10:25 ` Ivan Khoronzhuk
2014-05-19 10:25 ` Ivan Khoronzhuk
2014-05-19 10:25 ` [Patch v3 1/5] Power: reset: keystone-reset: introduce " Ivan Khoronzhuk
2014-05-19 10:25 ` Ivan Khoronzhuk
2014-05-19 10:25 ` Ivan Khoronzhuk
2014-05-19 10:25 ` [Patch v3 2/5] Power: reset: add bindings for " Ivan Khoronzhuk
2014-05-19 10:25 ` Ivan Khoronzhuk
2014-05-19 10:25 ` Ivan Khoronzhuk
2014-05-19 10:25 ` [Patch v3 3/5] ARM: keystone: remove redundant reset stuff Ivan Khoronzhuk
2014-05-19 10:25 ` Ivan Khoronzhuk
2014-05-19 10:25 ` Ivan Khoronzhuk
2014-05-19 10:25 ` [Patch v3 4/5] ARM: dts: keystone: update reset node to work with reset driver Ivan Khoronzhuk
2014-05-19 10:25 ` Ivan Khoronzhuk
2014-05-19 10:25 ` Ivan Khoronzhuk
2014-05-19 10:25 ` [Patch v3 5/5] ARM: keystone: enable reset driver support Ivan Khoronzhuk
2014-05-19 10:25 ` Ivan Khoronzhuk
2014-05-19 10:25 ` Ivan Khoronzhuk
2014-05-19 15:07 ` [Patch v3 0/5] Introduce keystone reset driver Santosh Shilimkar
2014-05-19 15:07 ` Santosh Shilimkar
2014-05-19 15:07 ` Santosh Shilimkar
2014-05-19 17:47 ` Arnd Bergmann
2014-05-19 17:47 ` Arnd Bergmann
2014-05-19 17:47 ` Arnd Bergmann
2014-05-20 13:16 ` Ivan Khoronzhuk
2014-05-20 13:16 ` Ivan Khoronzhuk
2014-05-20 13:16 ` Ivan Khoronzhuk
2014-05-20 13:44 ` Arnd Bergmann
2014-05-20 13:44 ` Arnd Bergmann
2014-05-20 13:44 ` Arnd Bergmann
2014-05-20 13:49 ` Santosh Shilimkar
2014-05-20 13:49 ` Santosh Shilimkar
2014-05-20 13:49 ` Santosh Shilimkar
2014-05-20 18:35 ` Ivan Khoronzhuk
2014-05-20 18:35 ` Ivan Khoronzhuk
2014-05-20 18:35 ` Ivan Khoronzhuk
2014-05-20 19:27 ` Arnd Bergmann
2014-05-20 19:27 ` Arnd Bergmann
2014-05-20 19:27 ` Arnd Bergmann
2014-05-21 14:28 ` Ivan Khoronzhuk
2014-05-21 14:28 ` Ivan Khoronzhuk
2014-05-21 14:28 ` Ivan Khoronzhuk
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.