* [PATCH v2 0/6] ARM: STi reset controller support
@ 2014-02-03 14:27 ` srinivas.kandagatla
0 siblings, 0 replies; 72+ messages in thread
From: srinivas.kandagatla at st.com @ 2014-02-03 14:27 UTC (permalink / raw)
To: linux-arm-kernel
From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
Hi All,
This patch series adds reset controller support for STi SOC series STiH415 and
STiH416. It adds support for both power down reset and soft reset controllers.
On STi series SOCs reset lines are wired up to system configuration registers.
Most of the IPs on STi SOCs are left in reset state, so this driver is very
important for other drivers to use the IPs.
Patch 01: Adds reset controller based on system configuration registers via
regmap.
Patch 02, 03: adds STiH415 and STiH416 reset controller drivers.
Patch 04, 05: adds STiH415 and STiH416 soft reset controllers.
The final patch 06 selects reset controller in mach-sti Kconfig.
I would like get this driver in to 3.15, so that its possible to add dt
support for other IPs with reset lines. Without this patchset its impossible
to add DT support to IPs with reset lines as reset line definition is in
common header file in include/dt-bindings/.
This reset controller will be used by gmac, i2c and st-ir drivers.
Comments?
Changes since v1:
- Added all the softreset lines.
- rebased to v3.14-rc1.
Thanks,
srini
Srinivas Kandagatla (2):
drivers: reset: stih415: add softreset controller
drivers: reset: stih416: add softreset controller
Stephen Gallimore (4):
drivers: reset: STi SoC system configuration reset controller support
drivers: reset: Reset controller driver for STiH415
drivers: reset: Reset controller driver for STiH416
ARM: STi: Add reset controller support to mach-sti Kconfig
.../devicetree/bindings/reset/st,sti-powerdown.txt | 47 +++++
.../devicetree/bindings/reset/st,sti-softreset.txt | 46 +++++
arch/arm/boot/dts/stih415.dtsi | 11 ++
arch/arm/boot/dts/stih416.dtsi | 11 ++
arch/arm/mach-sti/Kconfig | 3 +
drivers/reset/Kconfig | 2 +
drivers/reset/Makefile | 1 +
drivers/reset/sti/Kconfig | 15 ++
drivers/reset/sti/Makefile | 4 +
drivers/reset/sti/reset-stih415.c | 112 ++++++++++++
drivers/reset/sti/reset-stih416.c | 143 +++++++++++++++
drivers/reset/sti/reset-syscfg.c | 186 ++++++++++++++++++++
drivers/reset/sti/reset-syscfg.h | 69 ++++++++
.../dt-bindings/reset-controller/stih415-resets.h | 26 +++
.../dt-bindings/reset-controller/stih416-resets.h | 50 ++++++
15 files changed, 726 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
create mode 100644 Documentation/devicetree/bindings/reset/st,sti-softreset.txt
create mode 100644 drivers/reset/sti/Kconfig
create mode 100644 drivers/reset/sti/Makefile
create mode 100644 drivers/reset/sti/reset-stih415.c
create mode 100644 drivers/reset/sti/reset-stih416.c
create mode 100644 drivers/reset/sti/reset-syscfg.c
create mode 100644 drivers/reset/sti/reset-syscfg.h
create mode 100644 include/dt-bindings/reset-controller/stih415-resets.h
create mode 100644 include/dt-bindings/reset-controller/stih416-resets.h
--
1.7.9.5
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 0/6] ARM: STi reset controller support
@ 2014-02-03 14:27 ` srinivas.kandagatla
0 siblings, 0 replies; 72+ messages in thread
From: srinivas.kandagatla @ 2014-02-03 14:27 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Philipp Zabel, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Rob Landley, Russell King,
Srinivas Kandagatla, Stuart Menefy, Grant Likely, devicetree,
linux-doc, linux-kernel, kernel, Arnd Bergmann,
stephen.gallimore, Olof Johansson
From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
Hi All,
This patch series adds reset controller support for STi SOC series STiH415 and
STiH416. It adds support for both power down reset and soft reset controllers.
On STi series SOCs reset lines are wired up to system configuration registers.
Most of the IPs on STi SOCs are left in reset state, so this driver is very
important for other drivers to use the IPs.
Patch 01: Adds reset controller based on system configuration registers via
regmap.
Patch 02, 03: adds STiH415 and STiH416 reset controller drivers.
Patch 04, 05: adds STiH415 and STiH416 soft reset controllers.
The final patch 06 selects reset controller in mach-sti Kconfig.
I would like get this driver in to 3.15, so that its possible to add dt
support for other IPs with reset lines. Without this patchset its impossible
to add DT support to IPs with reset lines as reset line definition is in
common header file in include/dt-bindings/.
This reset controller will be used by gmac, i2c and st-ir drivers.
Comments?
Changes since v1:
- Added all the softreset lines.
- rebased to v3.14-rc1.
Thanks,
srini
Srinivas Kandagatla (2):
drivers: reset: stih415: add softreset controller
drivers: reset: stih416: add softreset controller
Stephen Gallimore (4):
drivers: reset: STi SoC system configuration reset controller support
drivers: reset: Reset controller driver for STiH415
drivers: reset: Reset controller driver for STiH416
ARM: STi: Add reset controller support to mach-sti Kconfig
.../devicetree/bindings/reset/st,sti-powerdown.txt | 47 +++++
.../devicetree/bindings/reset/st,sti-softreset.txt | 46 +++++
arch/arm/boot/dts/stih415.dtsi | 11 ++
arch/arm/boot/dts/stih416.dtsi | 11 ++
arch/arm/mach-sti/Kconfig | 3 +
drivers/reset/Kconfig | 2 +
drivers/reset/Makefile | 1 +
drivers/reset/sti/Kconfig | 15 ++
drivers/reset/sti/Makefile | 4 +
drivers/reset/sti/reset-stih415.c | 112 ++++++++++++
drivers/reset/sti/reset-stih416.c | 143 +++++++++++++++
drivers/reset/sti/reset-syscfg.c | 186 ++++++++++++++++++++
drivers/reset/sti/reset-syscfg.h | 69 ++++++++
.../dt-bindings/reset-controller/stih415-resets.h | 26 +++
.../dt-bindings/reset-controller/stih416-resets.h | 50 ++++++
15 files changed, 726 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
create mode 100644 Documentation/devicetree/bindings/reset/st,sti-softreset.txt
create mode 100644 drivers/reset/sti/Kconfig
create mode 100644 drivers/reset/sti/Makefile
create mode 100644 drivers/reset/sti/reset-stih415.c
create mode 100644 drivers/reset/sti/reset-stih416.c
create mode 100644 drivers/reset/sti/reset-syscfg.c
create mode 100644 drivers/reset/sti/reset-syscfg.h
create mode 100644 include/dt-bindings/reset-controller/stih415-resets.h
create mode 100644 include/dt-bindings/reset-controller/stih416-resets.h
--
1.7.9.5
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 1/6] drivers: reset: STi SoC system configuration reset controller support
2014-02-03 14:27 ` srinivas.kandagatla
(?)
@ 2014-02-03 14:28 ` srinivas.kandagatla
-1 siblings, 0 replies; 72+ messages in thread
From: srinivas.kandagatla @ 2014-02-03 14:28 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Philipp Zabel, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Rob Landley, Russell King,
Srinivas Kandagatla, Stuart Menefy, Grant Likely, devicetree,
linux-doc, linux-kernel, kernel, Arnd Bergmann,
stephen.gallimore, Olof Johansson
From: Stephen Gallimore <stephen.gallimore@st.com>
This patch adds a reset controller implementation for STMicroelectronics
STi family SoCs; it allows a group of related reset like controls found
in multiple system configuration registers to be represented by a single
controller device. System configuration registers are accessed through
the regmap framework and the mfd/syscon driver.
The implementation optionally supports waiting for the reset action to
be acknowledged in a separate status register and supports both
active high and active low reset lines. These properties are common across
all the reset channels in a specific reset controller instance, hence
all channels in a paritcular controller are expected to behave in the
same way.
Signed-off-by: Stephen Gallimore <stephen.gallimore@st.com>
---
drivers/reset/Kconfig | 2 +
drivers/reset/Makefile | 1 +
drivers/reset/sti/Kconfig | 7 ++
drivers/reset/sti/Makefile | 1 +
drivers/reset/sti/reset-syscfg.c | 186 ++++++++++++++++++++++++++++++++++++++
drivers/reset/sti/reset-syscfg.h | 69 ++++++++++++++
6 files changed, 266 insertions(+)
create mode 100644 drivers/reset/sti/Kconfig
create mode 100644 drivers/reset/sti/Makefile
create mode 100644 drivers/reset/sti/reset-syscfg.c
create mode 100644 drivers/reset/sti/reset-syscfg.h
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index c9d04f7..0615f50 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -11,3 +11,5 @@ menuconfig RESET_CONTROLLER
via GPIOs or SoC-internal reset controller modules.
If unsure, say no.
+
+source "drivers/reset/sti/Kconfig"
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index cc29832..4f60caf 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_RESET_CONTROLLER) += core.o
obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
+obj-$(CONFIG_ARCH_STI) += sti/
diff --git a/drivers/reset/sti/Kconfig b/drivers/reset/sti/Kconfig
new file mode 100644
index 0000000..ba13796
--- /dev/null
+++ b/drivers/reset/sti/Kconfig
@@ -0,0 +1,7 @@
+if ARCH_STI
+
+config STI_RESET_SYSCFG
+ bool
+ select RESET_CONTROLLER
+
+endif
diff --git a/drivers/reset/sti/Makefile b/drivers/reset/sti/Makefile
new file mode 100644
index 0000000..c4a51d9
--- /dev/null
+++ b/drivers/reset/sti/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_STI_RESET_SYSCFG) += reset-syscfg.o
diff --git a/drivers/reset/sti/reset-syscfg.c b/drivers/reset/sti/reset-syscfg.c
new file mode 100644
index 0000000..a145cc0
--- /dev/null
+++ b/drivers/reset/sti/reset-syscfg.c
@@ -0,0 +1,186 @@
+/*
+ * Copyright (C) 2013 STMicroelectronics Limited
+ * Author: Stephen Gallimore <stephen.gallimore@st.com>
+ *
+ * Inspired by mach-imx/src.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include <linux/kernel.h>
+#include <linux/platform_device.h>
+#include <linux/module.h>
+#include <linux/err.h>
+#include <linux/types.h>
+#include <linux/of_device.h>
+#include <linux/regmap.h>
+#include <linux/mfd/syscon.h>
+
+#include "reset-syscfg.h"
+
+/**
+ * Reset channel regmap configuration
+ *
+ * @reset: regmap field for the channel's reset bit.
+ * @ack: regmap field for the channel's ack bit (optional).
+ */
+struct syscfg_reset_channel {
+ struct regmap_field *reset;
+ struct regmap_field *ack;
+};
+
+/**
+ * A reset controller which groups together a set of related reset bits, which
+ * may be located in different system configuration registers.
+ *
+ * @rst: base reset controller structure.
+ * @active_low: are the resets in this controller active low, i.e. clearing
+ * the reset bit puts the hardware into reset.
+ * @channels: An array of reset channels for this controller.
+ */
+struct syscfg_reset_controller {
+ struct reset_controller_dev rst;
+ bool active_low;
+ struct syscfg_reset_channel *channels;
+};
+
+#define to_syscfg_reset_controller(_rst) \
+ container_of(_rst, struct syscfg_reset_controller, rst)
+
+static int syscfg_reset_program_hw(struct reset_controller_dev *rcdev,
+ unsigned long idx, int assert)
+{
+ struct syscfg_reset_controller *rst = to_syscfg_reset_controller(rcdev);
+ const struct syscfg_reset_channel *ch;
+ u32 ctrl_val = rst->active_low ? !assert : !!assert;
+ int err;
+
+ if (idx >= rcdev->nr_resets)
+ return -EINVAL;
+
+ ch = &rst->channels[idx];
+
+ err = regmap_field_write(ch->reset, ctrl_val);
+ if (err)
+ return err;
+
+ if (ch->ack) {
+ unsigned long timeout = jiffies + msecs_to_jiffies(1000);
+ u32 ack_val;
+
+ while (true) {
+ err = regmap_field_read(ch->ack, &ack_val);
+ if (err)
+ return err;
+
+ if (ack_val == ctrl_val)
+ break;
+
+ if (time_after(jiffies, timeout))
+ return -ETIME;
+
+ cpu_relax();
+ }
+ }
+
+ return 0;
+}
+
+static int syscfg_reset_assert(struct reset_controller_dev *rcdev,
+ unsigned long idx)
+{
+ return syscfg_reset_program_hw(rcdev, idx, true);
+}
+
+static int syscfg_reset_deassert(struct reset_controller_dev *rcdev,
+ unsigned long idx)
+{
+ return syscfg_reset_program_hw(rcdev, idx, false);
+}
+
+static int syscfg_reset_dev(struct reset_controller_dev *rcdev,
+ unsigned long idx)
+{
+ int err = syscfg_reset_assert(rcdev, idx);
+ if (err)
+ return err;
+
+ return syscfg_reset_deassert(rcdev, idx);
+}
+
+static struct reset_control_ops syscfg_reset_ops = {
+ .reset = syscfg_reset_dev,
+ .assert = syscfg_reset_assert,
+ .deassert = syscfg_reset_deassert,
+};
+
+static int syscfg_reset_controller_register(struct device *dev,
+ const struct syscfg_reset_controller_data *data)
+{
+ struct syscfg_reset_controller *rc;
+ size_t size;
+ int i, err;
+
+ rc = devm_kzalloc(dev, sizeof(*rc), GFP_KERNEL);
+ if (!rc)
+ return -ENOMEM;
+
+ size = sizeof(struct syscfg_reset_channel) * data->nr_channels;
+
+ rc->channels = devm_kzalloc(dev, size, GFP_KERNEL);
+ if (!rc->channels)
+ return -ENOMEM;
+
+ rc->rst.ops = &syscfg_reset_ops,
+ rc->rst.of_node = dev->of_node;
+ rc->rst.nr_resets = data->nr_channels;
+ rc->active_low = data->active_low;
+
+ for (i = 0; i < data->nr_channels; i++) {
+ struct regmap *map;
+ struct regmap_field *f;
+ const char *compatible = data->channels[i].compatible;
+
+ map = syscon_regmap_lookup_by_compatible(compatible);
+ if (IS_ERR(map))
+ return PTR_ERR(map);
+
+ f = devm_regmap_field_alloc(dev, map, data->channels[i].reset);
+ if (IS_ERR(f))
+ return PTR_ERR(f);
+
+ rc->channels[i].reset = f;
+
+ if (!data->wait_for_ack)
+ continue;
+
+ f = devm_regmap_field_alloc(dev, map, data->channels[i].ack);
+ if (IS_ERR(f))
+ return PTR_ERR(f);
+
+ rc->channels[i].ack = f;
+ }
+
+ err = reset_controller_register(&rc->rst);
+ if (!err)
+ dev_info(dev, "registered\n");
+
+ return err;
+}
+
+int syscfg_reset_probe(struct platform_device *pdev)
+{
+ struct device *dev = pdev ? &pdev->dev : NULL;
+ const struct of_device_id *match;
+
+ if (!dev || !dev->driver)
+ return -ENODEV;
+
+ match = of_match_device(dev->driver->of_match_table, dev);
+ if (!match || !match->data)
+ return -EINVAL;
+
+ return syscfg_reset_controller_register(dev, match->data);
+}
diff --git a/drivers/reset/sti/reset-syscfg.h b/drivers/reset/sti/reset-syscfg.h
new file mode 100644
index 0000000..2cc2283
--- /dev/null
+++ b/drivers/reset/sti/reset-syscfg.h
@@ -0,0 +1,69 @@
+/*
+ * Copyright (C) 2013 STMicroelectronics (R&D) Limited
+ * Author: Stephen Gallimore <stephen.gallimore@st.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#ifndef __STI_RESET_SYSCFG_H
+#define __STI_RESET_SYSCFG_H
+
+#include <linux/device.h>
+#include <linux/regmap.h>
+#include <linux/reset-controller.h>
+
+/**
+ * Reset channel description for a system configuration register based
+ * reset controller.
+ *
+ * @compatible: Compatible string of the syscon regmap containing this
+ * channel's control and ack (status) bits.
+ * @reset: Regmap field description of the channel's reset bit.
+ * @ack: Regmap field description of the channel's acknowledge bit.
+ */
+struct syscfg_reset_channel_data {
+ const char *compatible;
+ struct reg_field reset;
+ struct reg_field ack;
+};
+
+#define _SYSCFG_RST_CH(_c, _rr, _rb, _ar, _ab) \
+ { .compatible = _c, \
+ .reset = REG_FIELD(_rr, _rb, _rb), \
+ .ack = REG_FIELD(_ar, _ab, _ab), }
+
+#define _SYSCFG_RST_CH_NO_ACK(_c, _rr, _rb) \
+ { .compatible = _c, \
+ .reset = REG_FIELD(_rr, _rb, _rb), }
+
+/**
+ * Description of a system configuration register based reset controller.
+ *
+ * @wait_for_ack: The controller will wait for reset assert and de-assert to
+ * be "ack'd" in a channel's ack field.
+ * @active_low: Are the resets in this controller active low, i.e. clearing
+ * the reset bit puts the hardware into reset.
+ * @nr_channels: The number of reset channels in this controller.
+ * @channels: An array of reset channel descriptions.
+ */
+struct syscfg_reset_controller_data {
+ bool wait_for_ack;
+ bool active_low;
+ int nr_channels;
+ const struct syscfg_reset_channel_data *channels;
+};
+
+/**
+ * syscfg_reset_probe(): platform device probe function used by syscfg
+ * reset controller drivers. This registers a reset
+ * controller configured by the OF match data for
+ * the compatible device which should be of type
+ * "struct syscfg_reset_controller_data".
+ *
+ * @pdev: platform device
+ */
+int syscfg_reset_probe(struct platform_device *pdev);
+
+#endif /* __STI_RESET_SYSCFG_H */
--
1.7.9.5
^ permalink raw reply related [flat|nested] 72+ messages in thread* [PATCH v2 1/6] drivers: reset: STi SoC system configuration reset controller support
@ 2014-02-03 14:28 ` srinivas.kandagatla
0 siblings, 0 replies; 72+ messages in thread
From: srinivas.kandagatla at st.com @ 2014-02-03 14:28 UTC (permalink / raw)
To: linux-arm-kernel
From: Stephen Gallimore <stephen.gallimore@st.com>
This patch adds a reset controller implementation for STMicroelectronics
STi family SoCs; it allows a group of related reset like controls found
in multiple system configuration registers to be represented by a single
controller device. System configuration registers are accessed through
the regmap framework and the mfd/syscon driver.
The implementation optionally supports waiting for the reset action to
be acknowledged in a separate status register and supports both
active high and active low reset lines. These properties are common across
all the reset channels in a specific reset controller instance, hence
all channels in a paritcular controller are expected to behave in the
same way.
Signed-off-by: Stephen Gallimore <stephen.gallimore@st.com>
---
drivers/reset/Kconfig | 2 +
drivers/reset/Makefile | 1 +
drivers/reset/sti/Kconfig | 7 ++
drivers/reset/sti/Makefile | 1 +
drivers/reset/sti/reset-syscfg.c | 186 ++++++++++++++++++++++++++++++++++++++
drivers/reset/sti/reset-syscfg.h | 69 ++++++++++++++
6 files changed, 266 insertions(+)
create mode 100644 drivers/reset/sti/Kconfig
create mode 100644 drivers/reset/sti/Makefile
create mode 100644 drivers/reset/sti/reset-syscfg.c
create mode 100644 drivers/reset/sti/reset-syscfg.h
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index c9d04f7..0615f50 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -11,3 +11,5 @@ menuconfig RESET_CONTROLLER
via GPIOs or SoC-internal reset controller modules.
If unsure, say no.
+
+source "drivers/reset/sti/Kconfig"
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index cc29832..4f60caf 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_RESET_CONTROLLER) += core.o
obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
+obj-$(CONFIG_ARCH_STI) += sti/
diff --git a/drivers/reset/sti/Kconfig b/drivers/reset/sti/Kconfig
new file mode 100644
index 0000000..ba13796
--- /dev/null
+++ b/drivers/reset/sti/Kconfig
@@ -0,0 +1,7 @@
+if ARCH_STI
+
+config STI_RESET_SYSCFG
+ bool
+ select RESET_CONTROLLER
+
+endif
diff --git a/drivers/reset/sti/Makefile b/drivers/reset/sti/Makefile
new file mode 100644
index 0000000..c4a51d9
--- /dev/null
+++ b/drivers/reset/sti/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_STI_RESET_SYSCFG) += reset-syscfg.o
diff --git a/drivers/reset/sti/reset-syscfg.c b/drivers/reset/sti/reset-syscfg.c
new file mode 100644
index 0000000..a145cc0
--- /dev/null
+++ b/drivers/reset/sti/reset-syscfg.c
@@ -0,0 +1,186 @@
+/*
+ * Copyright (C) 2013 STMicroelectronics Limited
+ * Author: Stephen Gallimore <stephen.gallimore@st.com>
+ *
+ * Inspired by mach-imx/src.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include <linux/kernel.h>
+#include <linux/platform_device.h>
+#include <linux/module.h>
+#include <linux/err.h>
+#include <linux/types.h>
+#include <linux/of_device.h>
+#include <linux/regmap.h>
+#include <linux/mfd/syscon.h>
+
+#include "reset-syscfg.h"
+
+/**
+ * Reset channel regmap configuration
+ *
+ * @reset: regmap field for the channel's reset bit.
+ * @ack: regmap field for the channel's ack bit (optional).
+ */
+struct syscfg_reset_channel {
+ struct regmap_field *reset;
+ struct regmap_field *ack;
+};
+
+/**
+ * A reset controller which groups together a set of related reset bits, which
+ * may be located in different system configuration registers.
+ *
+ * @rst: base reset controller structure.
+ * @active_low: are the resets in this controller active low, i.e. clearing
+ * the reset bit puts the hardware into reset.
+ * @channels: An array of reset channels for this controller.
+ */
+struct syscfg_reset_controller {
+ struct reset_controller_dev rst;
+ bool active_low;
+ struct syscfg_reset_channel *channels;
+};
+
+#define to_syscfg_reset_controller(_rst) \
+ container_of(_rst, struct syscfg_reset_controller, rst)
+
+static int syscfg_reset_program_hw(struct reset_controller_dev *rcdev,
+ unsigned long idx, int assert)
+{
+ struct syscfg_reset_controller *rst = to_syscfg_reset_controller(rcdev);
+ const struct syscfg_reset_channel *ch;
+ u32 ctrl_val = rst->active_low ? !assert : !!assert;
+ int err;
+
+ if (idx >= rcdev->nr_resets)
+ return -EINVAL;
+
+ ch = &rst->channels[idx];
+
+ err = regmap_field_write(ch->reset, ctrl_val);
+ if (err)
+ return err;
+
+ if (ch->ack) {
+ unsigned long timeout = jiffies + msecs_to_jiffies(1000);
+ u32 ack_val;
+
+ while (true) {
+ err = regmap_field_read(ch->ack, &ack_val);
+ if (err)
+ return err;
+
+ if (ack_val == ctrl_val)
+ break;
+
+ if (time_after(jiffies, timeout))
+ return -ETIME;
+
+ cpu_relax();
+ }
+ }
+
+ return 0;
+}
+
+static int syscfg_reset_assert(struct reset_controller_dev *rcdev,
+ unsigned long idx)
+{
+ return syscfg_reset_program_hw(rcdev, idx, true);
+}
+
+static int syscfg_reset_deassert(struct reset_controller_dev *rcdev,
+ unsigned long idx)
+{
+ return syscfg_reset_program_hw(rcdev, idx, false);
+}
+
+static int syscfg_reset_dev(struct reset_controller_dev *rcdev,
+ unsigned long idx)
+{
+ int err = syscfg_reset_assert(rcdev, idx);
+ if (err)
+ return err;
+
+ return syscfg_reset_deassert(rcdev, idx);
+}
+
+static struct reset_control_ops syscfg_reset_ops = {
+ .reset = syscfg_reset_dev,
+ .assert = syscfg_reset_assert,
+ .deassert = syscfg_reset_deassert,
+};
+
+static int syscfg_reset_controller_register(struct device *dev,
+ const struct syscfg_reset_controller_data *data)
+{
+ struct syscfg_reset_controller *rc;
+ size_t size;
+ int i, err;
+
+ rc = devm_kzalloc(dev, sizeof(*rc), GFP_KERNEL);
+ if (!rc)
+ return -ENOMEM;
+
+ size = sizeof(struct syscfg_reset_channel) * data->nr_channels;
+
+ rc->channels = devm_kzalloc(dev, size, GFP_KERNEL);
+ if (!rc->channels)
+ return -ENOMEM;
+
+ rc->rst.ops = &syscfg_reset_ops,
+ rc->rst.of_node = dev->of_node;
+ rc->rst.nr_resets = data->nr_channels;
+ rc->active_low = data->active_low;
+
+ for (i = 0; i < data->nr_channels; i++) {
+ struct regmap *map;
+ struct regmap_field *f;
+ const char *compatible = data->channels[i].compatible;
+
+ map = syscon_regmap_lookup_by_compatible(compatible);
+ if (IS_ERR(map))
+ return PTR_ERR(map);
+
+ f = devm_regmap_field_alloc(dev, map, data->channels[i].reset);
+ if (IS_ERR(f))
+ return PTR_ERR(f);
+
+ rc->channels[i].reset = f;
+
+ if (!data->wait_for_ack)
+ continue;
+
+ f = devm_regmap_field_alloc(dev, map, data->channels[i].ack);
+ if (IS_ERR(f))
+ return PTR_ERR(f);
+
+ rc->channels[i].ack = f;
+ }
+
+ err = reset_controller_register(&rc->rst);
+ if (!err)
+ dev_info(dev, "registered\n");
+
+ return err;
+}
+
+int syscfg_reset_probe(struct platform_device *pdev)
+{
+ struct device *dev = pdev ? &pdev->dev : NULL;
+ const struct of_device_id *match;
+
+ if (!dev || !dev->driver)
+ return -ENODEV;
+
+ match = of_match_device(dev->driver->of_match_table, dev);
+ if (!match || !match->data)
+ return -EINVAL;
+
+ return syscfg_reset_controller_register(dev, match->data);
+}
diff --git a/drivers/reset/sti/reset-syscfg.h b/drivers/reset/sti/reset-syscfg.h
new file mode 100644
index 0000000..2cc2283
--- /dev/null
+++ b/drivers/reset/sti/reset-syscfg.h
@@ -0,0 +1,69 @@
+/*
+ * Copyright (C) 2013 STMicroelectronics (R&D) Limited
+ * Author: Stephen Gallimore <stephen.gallimore@st.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#ifndef __STI_RESET_SYSCFG_H
+#define __STI_RESET_SYSCFG_H
+
+#include <linux/device.h>
+#include <linux/regmap.h>
+#include <linux/reset-controller.h>
+
+/**
+ * Reset channel description for a system configuration register based
+ * reset controller.
+ *
+ * @compatible: Compatible string of the syscon regmap containing this
+ * channel's control and ack (status) bits.
+ * @reset: Regmap field description of the channel's reset bit.
+ * @ack: Regmap field description of the channel's acknowledge bit.
+ */
+struct syscfg_reset_channel_data {
+ const char *compatible;
+ struct reg_field reset;
+ struct reg_field ack;
+};
+
+#define _SYSCFG_RST_CH(_c, _rr, _rb, _ar, _ab) \
+ { .compatible = _c, \
+ .reset = REG_FIELD(_rr, _rb, _rb), \
+ .ack = REG_FIELD(_ar, _ab, _ab), }
+
+#define _SYSCFG_RST_CH_NO_ACK(_c, _rr, _rb) \
+ { .compatible = _c, \
+ .reset = REG_FIELD(_rr, _rb, _rb), }
+
+/**
+ * Description of a system configuration register based reset controller.
+ *
+ * @wait_for_ack: The controller will wait for reset assert and de-assert to
+ * be "ack'd" in a channel's ack field.
+ * @active_low: Are the resets in this controller active low, i.e. clearing
+ * the reset bit puts the hardware into reset.
+ * @nr_channels: The number of reset channels in this controller.
+ * @channels: An array of reset channel descriptions.
+ */
+struct syscfg_reset_controller_data {
+ bool wait_for_ack;
+ bool active_low;
+ int nr_channels;
+ const struct syscfg_reset_channel_data *channels;
+};
+
+/**
+ * syscfg_reset_probe(): platform device probe function used by syscfg
+ * reset controller drivers. This registers a reset
+ * controller configured by the OF match data for
+ * the compatible device which should be of type
+ * "struct syscfg_reset_controller_data".
+ *
+ * @pdev: platform device
+ */
+int syscfg_reset_probe(struct platform_device *pdev);
+
+#endif /* __STI_RESET_SYSCFG_H */
--
1.7.9.5
^ permalink raw reply related [flat|nested] 72+ messages in thread* [PATCH v2 1/6] drivers: reset: STi SoC system configuration reset controller support
@ 2014-02-03 14:28 ` srinivas.kandagatla
0 siblings, 0 replies; 72+ messages in thread
From: srinivas.kandagatla @ 2014-02-03 14:28 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Philipp Zabel, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Rob Landley, Russell King,
Srinivas Kandagatla, Stuart Menefy, Grant Likely, devicetree,
linux-doc, linux-kernel, kernel, Arnd Bergmann,
stephen.gallimore, Olof Johansson
From: Stephen Gallimore <stephen.gallimore@st.com>
This patch adds a reset controller implementation for STMicroelectronics
STi family SoCs; it allows a group of related reset like controls found
in multiple system configuration registers to be represented by a single
controller device. System configuration registers are accessed through
the regmap framework and the mfd/syscon driver.
The implementation optionally supports waiting for the reset action to
be acknowledged in a separate status register and supports both
active high and active low reset lines. These properties are common across
all the reset channels in a specific reset controller instance, hence
all channels in a paritcular controller are expected to behave in the
same way.
Signed-off-by: Stephen Gallimore <stephen.gallimore@st.com>
---
drivers/reset/Kconfig | 2 +
drivers/reset/Makefile | 1 +
drivers/reset/sti/Kconfig | 7 ++
drivers/reset/sti/Makefile | 1 +
drivers/reset/sti/reset-syscfg.c | 186 ++++++++++++++++++++++++++++++++++++++
drivers/reset/sti/reset-syscfg.h | 69 ++++++++++++++
6 files changed, 266 insertions(+)
create mode 100644 drivers/reset/sti/Kconfig
create mode 100644 drivers/reset/sti/Makefile
create mode 100644 drivers/reset/sti/reset-syscfg.c
create mode 100644 drivers/reset/sti/reset-syscfg.h
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index c9d04f7..0615f50 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -11,3 +11,5 @@ menuconfig RESET_CONTROLLER
via GPIOs or SoC-internal reset controller modules.
If unsure, say no.
+
+source "drivers/reset/sti/Kconfig"
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index cc29832..4f60caf 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_RESET_CONTROLLER) += core.o
obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
+obj-$(CONFIG_ARCH_STI) += sti/
diff --git a/drivers/reset/sti/Kconfig b/drivers/reset/sti/Kconfig
new file mode 100644
index 0000000..ba13796
--- /dev/null
+++ b/drivers/reset/sti/Kconfig
@@ -0,0 +1,7 @@
+if ARCH_STI
+
+config STI_RESET_SYSCFG
+ bool
+ select RESET_CONTROLLER
+
+endif
diff --git a/drivers/reset/sti/Makefile b/drivers/reset/sti/Makefile
new file mode 100644
index 0000000..c4a51d9
--- /dev/null
+++ b/drivers/reset/sti/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_STI_RESET_SYSCFG) += reset-syscfg.o
diff --git a/drivers/reset/sti/reset-syscfg.c b/drivers/reset/sti/reset-syscfg.c
new file mode 100644
index 0000000..a145cc0
--- /dev/null
+++ b/drivers/reset/sti/reset-syscfg.c
@@ -0,0 +1,186 @@
+/*
+ * Copyright (C) 2013 STMicroelectronics Limited
+ * Author: Stephen Gallimore <stephen.gallimore@st.com>
+ *
+ * Inspired by mach-imx/src.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include <linux/kernel.h>
+#include <linux/platform_device.h>
+#include <linux/module.h>
+#include <linux/err.h>
+#include <linux/types.h>
+#include <linux/of_device.h>
+#include <linux/regmap.h>
+#include <linux/mfd/syscon.h>
+
+#include "reset-syscfg.h"
+
+/**
+ * Reset channel regmap configuration
+ *
+ * @reset: regmap field for the channel's reset bit.
+ * @ack: regmap field for the channel's ack bit (optional).
+ */
+struct syscfg_reset_channel {
+ struct regmap_field *reset;
+ struct regmap_field *ack;
+};
+
+/**
+ * A reset controller which groups together a set of related reset bits, which
+ * may be located in different system configuration registers.
+ *
+ * @rst: base reset controller structure.
+ * @active_low: are the resets in this controller active low, i.e. clearing
+ * the reset bit puts the hardware into reset.
+ * @channels: An array of reset channels for this controller.
+ */
+struct syscfg_reset_controller {
+ struct reset_controller_dev rst;
+ bool active_low;
+ struct syscfg_reset_channel *channels;
+};
+
+#define to_syscfg_reset_controller(_rst) \
+ container_of(_rst, struct syscfg_reset_controller, rst)
+
+static int syscfg_reset_program_hw(struct reset_controller_dev *rcdev,
+ unsigned long idx, int assert)
+{
+ struct syscfg_reset_controller *rst = to_syscfg_reset_controller(rcdev);
+ const struct syscfg_reset_channel *ch;
+ u32 ctrl_val = rst->active_low ? !assert : !!assert;
+ int err;
+
+ if (idx >= rcdev->nr_resets)
+ return -EINVAL;
+
+ ch = &rst->channels[idx];
+
+ err = regmap_field_write(ch->reset, ctrl_val);
+ if (err)
+ return err;
+
+ if (ch->ack) {
+ unsigned long timeout = jiffies + msecs_to_jiffies(1000);
+ u32 ack_val;
+
+ while (true) {
+ err = regmap_field_read(ch->ack, &ack_val);
+ if (err)
+ return err;
+
+ if (ack_val == ctrl_val)
+ break;
+
+ if (time_after(jiffies, timeout))
+ return -ETIME;
+
+ cpu_relax();
+ }
+ }
+
+ return 0;
+}
+
+static int syscfg_reset_assert(struct reset_controller_dev *rcdev,
+ unsigned long idx)
+{
+ return syscfg_reset_program_hw(rcdev, idx, true);
+}
+
+static int syscfg_reset_deassert(struct reset_controller_dev *rcdev,
+ unsigned long idx)
+{
+ return syscfg_reset_program_hw(rcdev, idx, false);
+}
+
+static int syscfg_reset_dev(struct reset_controller_dev *rcdev,
+ unsigned long idx)
+{
+ int err = syscfg_reset_assert(rcdev, idx);
+ if (err)
+ return err;
+
+ return syscfg_reset_deassert(rcdev, idx);
+}
+
+static struct reset_control_ops syscfg_reset_ops = {
+ .reset = syscfg_reset_dev,
+ .assert = syscfg_reset_assert,
+ .deassert = syscfg_reset_deassert,
+};
+
+static int syscfg_reset_controller_register(struct device *dev,
+ const struct syscfg_reset_controller_data *data)
+{
+ struct syscfg_reset_controller *rc;
+ size_t size;
+ int i, err;
+
+ rc = devm_kzalloc(dev, sizeof(*rc), GFP_KERNEL);
+ if (!rc)
+ return -ENOMEM;
+
+ size = sizeof(struct syscfg_reset_channel) * data->nr_channels;
+
+ rc->channels = devm_kzalloc(dev, size, GFP_KERNEL);
+ if (!rc->channels)
+ return -ENOMEM;
+
+ rc->rst.ops = &syscfg_reset_ops,
+ rc->rst.of_node = dev->of_node;
+ rc->rst.nr_resets = data->nr_channels;
+ rc->active_low = data->active_low;
+
+ for (i = 0; i < data->nr_channels; i++) {
+ struct regmap *map;
+ struct regmap_field *f;
+ const char *compatible = data->channels[i].compatible;
+
+ map = syscon_regmap_lookup_by_compatible(compatible);
+ if (IS_ERR(map))
+ return PTR_ERR(map);
+
+ f = devm_regmap_field_alloc(dev, map, data->channels[i].reset);
+ if (IS_ERR(f))
+ return PTR_ERR(f);
+
+ rc->channels[i].reset = f;
+
+ if (!data->wait_for_ack)
+ continue;
+
+ f = devm_regmap_field_alloc(dev, map, data->channels[i].ack);
+ if (IS_ERR(f))
+ return PTR_ERR(f);
+
+ rc->channels[i].ack = f;
+ }
+
+ err = reset_controller_register(&rc->rst);
+ if (!err)
+ dev_info(dev, "registered\n");
+
+ return err;
+}
+
+int syscfg_reset_probe(struct platform_device *pdev)
+{
+ struct device *dev = pdev ? &pdev->dev : NULL;
+ const struct of_device_id *match;
+
+ if (!dev || !dev->driver)
+ return -ENODEV;
+
+ match = of_match_device(dev->driver->of_match_table, dev);
+ if (!match || !match->data)
+ return -EINVAL;
+
+ return syscfg_reset_controller_register(dev, match->data);
+}
diff --git a/drivers/reset/sti/reset-syscfg.h b/drivers/reset/sti/reset-syscfg.h
new file mode 100644
index 0000000..2cc2283
--- /dev/null
+++ b/drivers/reset/sti/reset-syscfg.h
@@ -0,0 +1,69 @@
+/*
+ * Copyright (C) 2013 STMicroelectronics (R&D) Limited
+ * Author: Stephen Gallimore <stephen.gallimore@st.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#ifndef __STI_RESET_SYSCFG_H
+#define __STI_RESET_SYSCFG_H
+
+#include <linux/device.h>
+#include <linux/regmap.h>
+#include <linux/reset-controller.h>
+
+/**
+ * Reset channel description for a system configuration register based
+ * reset controller.
+ *
+ * @compatible: Compatible string of the syscon regmap containing this
+ * channel's control and ack (status) bits.
+ * @reset: Regmap field description of the channel's reset bit.
+ * @ack: Regmap field description of the channel's acknowledge bit.
+ */
+struct syscfg_reset_channel_data {
+ const char *compatible;
+ struct reg_field reset;
+ struct reg_field ack;
+};
+
+#define _SYSCFG_RST_CH(_c, _rr, _rb, _ar, _ab) \
+ { .compatible = _c, \
+ .reset = REG_FIELD(_rr, _rb, _rb), \
+ .ack = REG_FIELD(_ar, _ab, _ab), }
+
+#define _SYSCFG_RST_CH_NO_ACK(_c, _rr, _rb) \
+ { .compatible = _c, \
+ .reset = REG_FIELD(_rr, _rb, _rb), }
+
+/**
+ * Description of a system configuration register based reset controller.
+ *
+ * @wait_for_ack: The controller will wait for reset assert and de-assert to
+ * be "ack'd" in a channel's ack field.
+ * @active_low: Are the resets in this controller active low, i.e. clearing
+ * the reset bit puts the hardware into reset.
+ * @nr_channels: The number of reset channels in this controller.
+ * @channels: An array of reset channel descriptions.
+ */
+struct syscfg_reset_controller_data {
+ bool wait_for_ack;
+ bool active_low;
+ int nr_channels;
+ const struct syscfg_reset_channel_data *channels;
+};
+
+/**
+ * syscfg_reset_probe(): platform device probe function used by syscfg
+ * reset controller drivers. This registers a reset
+ * controller configured by the OF match data for
+ * the compatible device which should be of type
+ * "struct syscfg_reset_controller_data".
+ *
+ * @pdev: platform device
+ */
+int syscfg_reset_probe(struct platform_device *pdev);
+
+#endif /* __STI_RESET_SYSCFG_H */
--
1.7.9.5
^ permalink raw reply related [flat|nested] 72+ messages in thread
* [PATCH v2 2/6] drivers: reset: Reset controller driver for STiH415
2014-02-03 14:27 ` srinivas.kandagatla
(?)
@ 2014-02-03 14:28 ` srinivas.kandagatla
-1 siblings, 0 replies; 72+ messages in thread
From: srinivas.kandagatla @ 2014-02-03 14:28 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Philipp Zabel, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Rob Landley, Russell King,
Srinivas Kandagatla, Stuart Menefy, Grant Likely, devicetree,
linux-doc, linux-kernel, kernel, Arnd Bergmann,
stephen.gallimore, Olof Johansson
From: Stephen Gallimore <stephen.gallimore@st.com>
This patch adds a reset controller platform driver for the STiH415
SoC. This initial version provides a compatible driver for the
"st,stih415-powerdown" device, which registers a system configuration
register based reset controller that controls the powerdown state of
hardware such as the on-chip USB host controllers.
Signed-off-by: Stephen Gallimore <stephen.gallimore@st.com>
---
.../devicetree/bindings/reset/st,sti-powerdown.txt | 47 ++++++++++++
arch/arm/boot/dts/stih415.dtsi | 6 ++
drivers/reset/sti/Kconfig | 4 +
drivers/reset/sti/Makefile | 3 +
drivers/reset/sti/reset-stih415.c | 77 ++++++++++++++++++++
.../dt-bindings/reset-controller/stih415-resets.h | 19 +++++
6 files changed, 156 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
create mode 100644 drivers/reset/sti/reset-stih415.c
create mode 100644 include/dt-bindings/reset-controller/stih415-resets.h
diff --git a/Documentation/devicetree/bindings/reset/st,sti-powerdown.txt b/Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
new file mode 100644
index 0000000..5ab26b7
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
@@ -0,0 +1,47 @@
+STMicroelectronics STi family Sysconfig Peripheral Powerdown Reset Controller
+=============================================================================
+
+This binding describes a reset controller device that is used to enable and
+disable on-chip peripheral controllers such as USB and SATA, using
+"powerdown" control bits found in the STi family SoC system configuration
+registers. These have been grouped together into a single reset controller
+device for convenience.
+
+The actual action taken when powerdown is asserted is hardware dependent.
+However, when asserted it may not be possible to access the hardware's
+registers and after an assert/deassert sequence the hardware's previous state
+may no longer be valid.
+
+Please refer to reset.txt in this directory for common reset
+controller binding usage.
+
+Required properties:
+- compatible: Should be "st,<chip>-powerdown"
+ ex: "st,stih415-powerdown", "st,stih416-powerdown"
+- #reset-cells: 1, see below
+
+example:
+
+ powerdown: powerdown-controller {
+ #reset-cells = <1>;
+ compatible = "st,stih415-powerdown";
+ };
+
+
+Specifying powerdown control of devices
+=======================================
+
+Device nodes should specify the reset channel required in their "resets"
+property, containing a phandle to the powerdown device node and an
+index specifying which channel to use, as described in reset.txt
+
+example:
+
+ usb1: usb@fe200000 {
+ resets = <&powerdown STIH41X_USB1_POWERDOWN>;
+ };
+
+Macro definitions for the supported reset channels can be found in:
+
+include/dt-bindings/reset-controller/stih415-resets.h
+include/dt-bindings/reset-controller/stih416-resets.h
diff --git a/arch/arm/boot/dts/stih415.dtsi b/arch/arm/boot/dts/stih415.dtsi
index d9c7dd1..19e29f4 100644
--- a/arch/arm/boot/dts/stih415.dtsi
+++ b/arch/arm/boot/dts/stih415.dtsi
@@ -10,6 +10,7 @@
#include "stih415-clock.dtsi"
#include "stih415-pinctrl.dtsi"
#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/reset-controller/stih415-resets.h>
/ {
L2: cache-controller {
@@ -28,6 +29,11 @@
ranges;
compatible = "simple-bus";
+ powerdown: powerdown-controller {
+ #reset-cells = <1>;
+ compatible = "st,stih415-powerdown";
+ };
+
syscfg_sbc: sbc-syscfg@fe600000{
compatible = "st,stih415-sbc-syscfg", "syscon";
reg = <0xfe600000 0xb4>;
diff --git a/drivers/reset/sti/Kconfig b/drivers/reset/sti/Kconfig
index ba13796..ef6654a 100644
--- a/drivers/reset/sti/Kconfig
+++ b/drivers/reset/sti/Kconfig
@@ -4,4 +4,8 @@ config STI_RESET_SYSCFG
bool
select RESET_CONTROLLER
+config STIH415_RESET
+ bool
+ select STI_RESET_SYSCFG
+
endif
diff --git a/drivers/reset/sti/Makefile b/drivers/reset/sti/Makefile
index c4a51d9..fce4433 100644
--- a/drivers/reset/sti/Makefile
+++ b/drivers/reset/sti/Makefile
@@ -1 +1,4 @@
obj-$(CONFIG_STI_RESET_SYSCFG) += reset-syscfg.o
+
+# SoC specific reset devices
+obj-$(CONFIG_STIH415_RESET) += reset-stih415.o
diff --git a/drivers/reset/sti/reset-stih415.c b/drivers/reset/sti/reset-stih415.c
new file mode 100644
index 0000000..56c2146
--- /dev/null
+++ b/drivers/reset/sti/reset-stih415.c
@@ -0,0 +1,77 @@
+/*
+ * Copyright (C) 2013 STMicroelectronics (R&D) Limited
+ * Author: Stephen Gallimore <stephen.gallimore@st.com>
+ * Author: Srinivas Kandagatla <srinivas.kandagatla@st.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+
+#include <dt-bindings/reset-controller/stih415-resets.h>
+
+#include "reset-syscfg.h"
+
+/*
+ * STiH415 Peripheral powerdown definitions.
+ */
+static const char stih415_front[] = "st,stih415-front-syscfg";
+static const char stih415_rear[] = "st,stih415-rear-syscfg";
+static const char stih415_sbc[] = "st,stih415-sbc-syscfg";
+static const char stih415_lpm[] = "st,stih415-lpm-syscfg";
+
+#define STIH415_PDN_FRONT(_bit) \
+ _SYSCFG_RST_CH(stih415_front, SYSCFG_114, _bit, SYSSTAT_187, _bit)
+
+#define STIH415_PDN_REAR(_cntl, _stat) \
+ _SYSCFG_RST_CH(stih415_rear, SYSCFG_336, _cntl, SYSSTAT_384, _stat)
+
+#define SYSCFG_114 0x38 /* Powerdown request EMI/NAND/Keyscan */
+#define SYSSTAT_187 0x15c /* Powerdown status EMI/NAND/Keyscan */
+
+#define SYSCFG_336 0x90 /* Powerdown request USB/SATA/PCIe */
+#define SYSSTAT_384 0x150 /* Powerdown status USB/SATA/PCIe */
+
+static const struct syscfg_reset_channel_data stih415_powerdowns[] = {
+ [STIH415_EMISS_POWERDOWN] = STIH415_PDN_FRONT(0),
+ [STIH415_NAND_POWERDOWN] = STIH415_PDN_FRONT(1),
+ [STIH415_KEYSCAN_POWERDOWN] = STIH415_PDN_FRONT(2),
+ [STIH415_USB0_POWERDOWN] = STIH415_PDN_REAR(0, 0),
+ [STIH415_USB1_POWERDOWN] = STIH415_PDN_REAR(1, 1),
+ [STIH415_USB2_POWERDOWN] = STIH415_PDN_REAR(2, 2),
+ [STIH415_SATA0_POWERDOWN] = STIH415_PDN_REAR(3, 3),
+ [STIH415_SATA1_POWERDOWN] = STIH415_PDN_REAR(4, 4),
+ [STIH415_PCIE_POWERDOWN] = STIH415_PDN_REAR(5, 8),
+};
+
+static struct syscfg_reset_controller_data stih415_powerdown_controller = {
+ .wait_for_ack = true,
+ .nr_channels = ARRAY_SIZE(stih415_powerdowns),
+ .channels = stih415_powerdowns,
+};
+
+static struct of_device_id stih415_reset_match[] = {
+ { .compatible = "st,stih415-powerdown",
+ .data = &stih415_powerdown_controller, },
+ {},
+};
+
+static struct platform_driver stih415_reset_driver = {
+ .probe = syscfg_reset_probe,
+ .driver = {
+ .name = "reset-stih415",
+ .owner = THIS_MODULE,
+ .of_match_table = stih415_reset_match,
+ },
+};
+
+static int __init stih415_reset_init(void)
+{
+ return platform_driver_register(&stih415_reset_driver);
+}
+arch_initcall(stih415_reset_init);
diff --git a/include/dt-bindings/reset-controller/stih415-resets.h b/include/dt-bindings/reset-controller/stih415-resets.h
new file mode 100644
index 0000000..2d54e68
--- /dev/null
+++ b/include/dt-bindings/reset-controller/stih415-resets.h
@@ -0,0 +1,19 @@
+/*
+ * This header provides constants for the reset controller
+ * based peripheral powerdown requests on the STMicroelectronics
+ * STiH415 SoC.
+ */
+#ifndef _DT_BINDINGS_RESET_CONTROLLER_STIH415
+#define _DT_BINDINGS_RESET_CONTROLLER_STIH415
+
+#define STIH415_EMISS_POWERDOWN 0
+#define STIH415_NAND_POWERDOWN 1
+#define STIH415_KEYSCAN_POWERDOWN 2
+#define STIH415_USB0_POWERDOWN 3
+#define STIH415_USB1_POWERDOWN 4
+#define STIH415_USB2_POWERDOWN 5
+#define STIH415_SATA0_POWERDOWN 6
+#define STIH415_SATA1_POWERDOWN 7
+#define STIH415_PCIE_POWERDOWN 8
+
+#endif /* _DT_BINDINGS_RESET_CONTROLLER_STIH415 */
--
1.7.9.5
^ permalink raw reply related [flat|nested] 72+ messages in thread* [PATCH v2 2/6] drivers: reset: Reset controller driver for STiH415
@ 2014-02-03 14:28 ` srinivas.kandagatla
0 siblings, 0 replies; 72+ messages in thread
From: srinivas.kandagatla at st.com @ 2014-02-03 14:28 UTC (permalink / raw)
To: linux-arm-kernel
From: Stephen Gallimore <stephen.gallimore@st.com>
This patch adds a reset controller platform driver for the STiH415
SoC. This initial version provides a compatible driver for the
"st,stih415-powerdown" device, which registers a system configuration
register based reset controller that controls the powerdown state of
hardware such as the on-chip USB host controllers.
Signed-off-by: Stephen Gallimore <stephen.gallimore@st.com>
---
.../devicetree/bindings/reset/st,sti-powerdown.txt | 47 ++++++++++++
arch/arm/boot/dts/stih415.dtsi | 6 ++
drivers/reset/sti/Kconfig | 4 +
drivers/reset/sti/Makefile | 3 +
drivers/reset/sti/reset-stih415.c | 77 ++++++++++++++++++++
.../dt-bindings/reset-controller/stih415-resets.h | 19 +++++
6 files changed, 156 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
create mode 100644 drivers/reset/sti/reset-stih415.c
create mode 100644 include/dt-bindings/reset-controller/stih415-resets.h
diff --git a/Documentation/devicetree/bindings/reset/st,sti-powerdown.txt b/Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
new file mode 100644
index 0000000..5ab26b7
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
@@ -0,0 +1,47 @@
+STMicroelectronics STi family Sysconfig Peripheral Powerdown Reset Controller
+=============================================================================
+
+This binding describes a reset controller device that is used to enable and
+disable on-chip peripheral controllers such as USB and SATA, using
+"powerdown" control bits found in the STi family SoC system configuration
+registers. These have been grouped together into a single reset controller
+device for convenience.
+
+The actual action taken when powerdown is asserted is hardware dependent.
+However, when asserted it may not be possible to access the hardware's
+registers and after an assert/deassert sequence the hardware's previous state
+may no longer be valid.
+
+Please refer to reset.txt in this directory for common reset
+controller binding usage.
+
+Required properties:
+- compatible: Should be "st,<chip>-powerdown"
+ ex: "st,stih415-powerdown", "st,stih416-powerdown"
+- #reset-cells: 1, see below
+
+example:
+
+ powerdown: powerdown-controller {
+ #reset-cells = <1>;
+ compatible = "st,stih415-powerdown";
+ };
+
+
+Specifying powerdown control of devices
+=======================================
+
+Device nodes should specify the reset channel required in their "resets"
+property, containing a phandle to the powerdown device node and an
+index specifying which channel to use, as described in reset.txt
+
+example:
+
+ usb1: usb at fe200000 {
+ resets = <&powerdown STIH41X_USB1_POWERDOWN>;
+ };
+
+Macro definitions for the supported reset channels can be found in:
+
+include/dt-bindings/reset-controller/stih415-resets.h
+include/dt-bindings/reset-controller/stih416-resets.h
diff --git a/arch/arm/boot/dts/stih415.dtsi b/arch/arm/boot/dts/stih415.dtsi
index d9c7dd1..19e29f4 100644
--- a/arch/arm/boot/dts/stih415.dtsi
+++ b/arch/arm/boot/dts/stih415.dtsi
@@ -10,6 +10,7 @@
#include "stih415-clock.dtsi"
#include "stih415-pinctrl.dtsi"
#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/reset-controller/stih415-resets.h>
/ {
L2: cache-controller {
@@ -28,6 +29,11 @@
ranges;
compatible = "simple-bus";
+ powerdown: powerdown-controller {
+ #reset-cells = <1>;
+ compatible = "st,stih415-powerdown";
+ };
+
syscfg_sbc: sbc-syscfg at fe600000{
compatible = "st,stih415-sbc-syscfg", "syscon";
reg = <0xfe600000 0xb4>;
diff --git a/drivers/reset/sti/Kconfig b/drivers/reset/sti/Kconfig
index ba13796..ef6654a 100644
--- a/drivers/reset/sti/Kconfig
+++ b/drivers/reset/sti/Kconfig
@@ -4,4 +4,8 @@ config STI_RESET_SYSCFG
bool
select RESET_CONTROLLER
+config STIH415_RESET
+ bool
+ select STI_RESET_SYSCFG
+
endif
diff --git a/drivers/reset/sti/Makefile b/drivers/reset/sti/Makefile
index c4a51d9..fce4433 100644
--- a/drivers/reset/sti/Makefile
+++ b/drivers/reset/sti/Makefile
@@ -1 +1,4 @@
obj-$(CONFIG_STI_RESET_SYSCFG) += reset-syscfg.o
+
+# SoC specific reset devices
+obj-$(CONFIG_STIH415_RESET) += reset-stih415.o
diff --git a/drivers/reset/sti/reset-stih415.c b/drivers/reset/sti/reset-stih415.c
new file mode 100644
index 0000000..56c2146
--- /dev/null
+++ b/drivers/reset/sti/reset-stih415.c
@@ -0,0 +1,77 @@
+/*
+ * Copyright (C) 2013 STMicroelectronics (R&D) Limited
+ * Author: Stephen Gallimore <stephen.gallimore@st.com>
+ * Author: Srinivas Kandagatla <srinivas.kandagatla@st.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+
+#include <dt-bindings/reset-controller/stih415-resets.h>
+
+#include "reset-syscfg.h"
+
+/*
+ * STiH415 Peripheral powerdown definitions.
+ */
+static const char stih415_front[] = "st,stih415-front-syscfg";
+static const char stih415_rear[] = "st,stih415-rear-syscfg";
+static const char stih415_sbc[] = "st,stih415-sbc-syscfg";
+static const char stih415_lpm[] = "st,stih415-lpm-syscfg";
+
+#define STIH415_PDN_FRONT(_bit) \
+ _SYSCFG_RST_CH(stih415_front, SYSCFG_114, _bit, SYSSTAT_187, _bit)
+
+#define STIH415_PDN_REAR(_cntl, _stat) \
+ _SYSCFG_RST_CH(stih415_rear, SYSCFG_336, _cntl, SYSSTAT_384, _stat)
+
+#define SYSCFG_114 0x38 /* Powerdown request EMI/NAND/Keyscan */
+#define SYSSTAT_187 0x15c /* Powerdown status EMI/NAND/Keyscan */
+
+#define SYSCFG_336 0x90 /* Powerdown request USB/SATA/PCIe */
+#define SYSSTAT_384 0x150 /* Powerdown status USB/SATA/PCIe */
+
+static const struct syscfg_reset_channel_data stih415_powerdowns[] = {
+ [STIH415_EMISS_POWERDOWN] = STIH415_PDN_FRONT(0),
+ [STIH415_NAND_POWERDOWN] = STIH415_PDN_FRONT(1),
+ [STIH415_KEYSCAN_POWERDOWN] = STIH415_PDN_FRONT(2),
+ [STIH415_USB0_POWERDOWN] = STIH415_PDN_REAR(0, 0),
+ [STIH415_USB1_POWERDOWN] = STIH415_PDN_REAR(1, 1),
+ [STIH415_USB2_POWERDOWN] = STIH415_PDN_REAR(2, 2),
+ [STIH415_SATA0_POWERDOWN] = STIH415_PDN_REAR(3, 3),
+ [STIH415_SATA1_POWERDOWN] = STIH415_PDN_REAR(4, 4),
+ [STIH415_PCIE_POWERDOWN] = STIH415_PDN_REAR(5, 8),
+};
+
+static struct syscfg_reset_controller_data stih415_powerdown_controller = {
+ .wait_for_ack = true,
+ .nr_channels = ARRAY_SIZE(stih415_powerdowns),
+ .channels = stih415_powerdowns,
+};
+
+static struct of_device_id stih415_reset_match[] = {
+ { .compatible = "st,stih415-powerdown",
+ .data = &stih415_powerdown_controller, },
+ {},
+};
+
+static struct platform_driver stih415_reset_driver = {
+ .probe = syscfg_reset_probe,
+ .driver = {
+ .name = "reset-stih415",
+ .owner = THIS_MODULE,
+ .of_match_table = stih415_reset_match,
+ },
+};
+
+static int __init stih415_reset_init(void)
+{
+ return platform_driver_register(&stih415_reset_driver);
+}
+arch_initcall(stih415_reset_init);
diff --git a/include/dt-bindings/reset-controller/stih415-resets.h b/include/dt-bindings/reset-controller/stih415-resets.h
new file mode 100644
index 0000000..2d54e68
--- /dev/null
+++ b/include/dt-bindings/reset-controller/stih415-resets.h
@@ -0,0 +1,19 @@
+/*
+ * This header provides constants for the reset controller
+ * based peripheral powerdown requests on the STMicroelectronics
+ * STiH415 SoC.
+ */
+#ifndef _DT_BINDINGS_RESET_CONTROLLER_STIH415
+#define _DT_BINDINGS_RESET_CONTROLLER_STIH415
+
+#define STIH415_EMISS_POWERDOWN 0
+#define STIH415_NAND_POWERDOWN 1
+#define STIH415_KEYSCAN_POWERDOWN 2
+#define STIH415_USB0_POWERDOWN 3
+#define STIH415_USB1_POWERDOWN 4
+#define STIH415_USB2_POWERDOWN 5
+#define STIH415_SATA0_POWERDOWN 6
+#define STIH415_SATA1_POWERDOWN 7
+#define STIH415_PCIE_POWERDOWN 8
+
+#endif /* _DT_BINDINGS_RESET_CONTROLLER_STIH415 */
--
1.7.9.5
^ permalink raw reply related [flat|nested] 72+ messages in thread* [PATCH v2 2/6] drivers: reset: Reset controller driver for STiH415
@ 2014-02-03 14:28 ` srinivas.kandagatla
0 siblings, 0 replies; 72+ messages in thread
From: srinivas.kandagatla @ 2014-02-03 14:28 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, devicetree, Russell King, Rob Landley, Pawel Moll,
Ian Campbell, Olof Johansson, Srinivas Kandagatla, linux-doc,
linux-kernel, stephen.gallimore, Stuart Menefy, Rob Herring,
Arnd Bergmann, Philipp Zabel, Kumar Gala, Grant Likely, kernel
From: Stephen Gallimore <stephen.gallimore@st.com>
This patch adds a reset controller platform driver for the STiH415
SoC. This initial version provides a compatible driver for the
"st,stih415-powerdown" device, which registers a system configuration
register based reset controller that controls the powerdown state of
hardware such as the on-chip USB host controllers.
Signed-off-by: Stephen Gallimore <stephen.gallimore@st.com>
---
.../devicetree/bindings/reset/st,sti-powerdown.txt | 47 ++++++++++++
arch/arm/boot/dts/stih415.dtsi | 6 ++
drivers/reset/sti/Kconfig | 4 +
drivers/reset/sti/Makefile | 3 +
drivers/reset/sti/reset-stih415.c | 77 ++++++++++++++++++++
.../dt-bindings/reset-controller/stih415-resets.h | 19 +++++
6 files changed, 156 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
create mode 100644 drivers/reset/sti/reset-stih415.c
create mode 100644 include/dt-bindings/reset-controller/stih415-resets.h
diff --git a/Documentation/devicetree/bindings/reset/st,sti-powerdown.txt b/Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
new file mode 100644
index 0000000..5ab26b7
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
@@ -0,0 +1,47 @@
+STMicroelectronics STi family Sysconfig Peripheral Powerdown Reset Controller
+=============================================================================
+
+This binding describes a reset controller device that is used to enable and
+disable on-chip peripheral controllers such as USB and SATA, using
+"powerdown" control bits found in the STi family SoC system configuration
+registers. These have been grouped together into a single reset controller
+device for convenience.
+
+The actual action taken when powerdown is asserted is hardware dependent.
+However, when asserted it may not be possible to access the hardware's
+registers and after an assert/deassert sequence the hardware's previous state
+may no longer be valid.
+
+Please refer to reset.txt in this directory for common reset
+controller binding usage.
+
+Required properties:
+- compatible: Should be "st,<chip>-powerdown"
+ ex: "st,stih415-powerdown", "st,stih416-powerdown"
+- #reset-cells: 1, see below
+
+example:
+
+ powerdown: powerdown-controller {
+ #reset-cells = <1>;
+ compatible = "st,stih415-powerdown";
+ };
+
+
+Specifying powerdown control of devices
+=======================================
+
+Device nodes should specify the reset channel required in their "resets"
+property, containing a phandle to the powerdown device node and an
+index specifying which channel to use, as described in reset.txt
+
+example:
+
+ usb1: usb@fe200000 {
+ resets = <&powerdown STIH41X_USB1_POWERDOWN>;
+ };
+
+Macro definitions for the supported reset channels can be found in:
+
+include/dt-bindings/reset-controller/stih415-resets.h
+include/dt-bindings/reset-controller/stih416-resets.h
diff --git a/arch/arm/boot/dts/stih415.dtsi b/arch/arm/boot/dts/stih415.dtsi
index d9c7dd1..19e29f4 100644
--- a/arch/arm/boot/dts/stih415.dtsi
+++ b/arch/arm/boot/dts/stih415.dtsi
@@ -10,6 +10,7 @@
#include "stih415-clock.dtsi"
#include "stih415-pinctrl.dtsi"
#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/reset-controller/stih415-resets.h>
/ {
L2: cache-controller {
@@ -28,6 +29,11 @@
ranges;
compatible = "simple-bus";
+ powerdown: powerdown-controller {
+ #reset-cells = <1>;
+ compatible = "st,stih415-powerdown";
+ };
+
syscfg_sbc: sbc-syscfg@fe600000{
compatible = "st,stih415-sbc-syscfg", "syscon";
reg = <0xfe600000 0xb4>;
diff --git a/drivers/reset/sti/Kconfig b/drivers/reset/sti/Kconfig
index ba13796..ef6654a 100644
--- a/drivers/reset/sti/Kconfig
+++ b/drivers/reset/sti/Kconfig
@@ -4,4 +4,8 @@ config STI_RESET_SYSCFG
bool
select RESET_CONTROLLER
+config STIH415_RESET
+ bool
+ select STI_RESET_SYSCFG
+
endif
diff --git a/drivers/reset/sti/Makefile b/drivers/reset/sti/Makefile
index c4a51d9..fce4433 100644
--- a/drivers/reset/sti/Makefile
+++ b/drivers/reset/sti/Makefile
@@ -1 +1,4 @@
obj-$(CONFIG_STI_RESET_SYSCFG) += reset-syscfg.o
+
+# SoC specific reset devices
+obj-$(CONFIG_STIH415_RESET) += reset-stih415.o
diff --git a/drivers/reset/sti/reset-stih415.c b/drivers/reset/sti/reset-stih415.c
new file mode 100644
index 0000000..56c2146
--- /dev/null
+++ b/drivers/reset/sti/reset-stih415.c
@@ -0,0 +1,77 @@
+/*
+ * Copyright (C) 2013 STMicroelectronics (R&D) Limited
+ * Author: Stephen Gallimore <stephen.gallimore@st.com>
+ * Author: Srinivas Kandagatla <srinivas.kandagatla@st.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+
+#include <dt-bindings/reset-controller/stih415-resets.h>
+
+#include "reset-syscfg.h"
+
+/*
+ * STiH415 Peripheral powerdown definitions.
+ */
+static const char stih415_front[] = "st,stih415-front-syscfg";
+static const char stih415_rear[] = "st,stih415-rear-syscfg";
+static const char stih415_sbc[] = "st,stih415-sbc-syscfg";
+static const char stih415_lpm[] = "st,stih415-lpm-syscfg";
+
+#define STIH415_PDN_FRONT(_bit) \
+ _SYSCFG_RST_CH(stih415_front, SYSCFG_114, _bit, SYSSTAT_187, _bit)
+
+#define STIH415_PDN_REAR(_cntl, _stat) \
+ _SYSCFG_RST_CH(stih415_rear, SYSCFG_336, _cntl, SYSSTAT_384, _stat)
+
+#define SYSCFG_114 0x38 /* Powerdown request EMI/NAND/Keyscan */
+#define SYSSTAT_187 0x15c /* Powerdown status EMI/NAND/Keyscan */
+
+#define SYSCFG_336 0x90 /* Powerdown request USB/SATA/PCIe */
+#define SYSSTAT_384 0x150 /* Powerdown status USB/SATA/PCIe */
+
+static const struct syscfg_reset_channel_data stih415_powerdowns[] = {
+ [STIH415_EMISS_POWERDOWN] = STIH415_PDN_FRONT(0),
+ [STIH415_NAND_POWERDOWN] = STIH415_PDN_FRONT(1),
+ [STIH415_KEYSCAN_POWERDOWN] = STIH415_PDN_FRONT(2),
+ [STIH415_USB0_POWERDOWN] = STIH415_PDN_REAR(0, 0),
+ [STIH415_USB1_POWERDOWN] = STIH415_PDN_REAR(1, 1),
+ [STIH415_USB2_POWERDOWN] = STIH415_PDN_REAR(2, 2),
+ [STIH415_SATA0_POWERDOWN] = STIH415_PDN_REAR(3, 3),
+ [STIH415_SATA1_POWERDOWN] = STIH415_PDN_REAR(4, 4),
+ [STIH415_PCIE_POWERDOWN] = STIH415_PDN_REAR(5, 8),
+};
+
+static struct syscfg_reset_controller_data stih415_powerdown_controller = {
+ .wait_for_ack = true,
+ .nr_channels = ARRAY_SIZE(stih415_powerdowns),
+ .channels = stih415_powerdowns,
+};
+
+static struct of_device_id stih415_reset_match[] = {
+ { .compatible = "st,stih415-powerdown",
+ .data = &stih415_powerdown_controller, },
+ {},
+};
+
+static struct platform_driver stih415_reset_driver = {
+ .probe = syscfg_reset_probe,
+ .driver = {
+ .name = "reset-stih415",
+ .owner = THIS_MODULE,
+ .of_match_table = stih415_reset_match,
+ },
+};
+
+static int __init stih415_reset_init(void)
+{
+ return platform_driver_register(&stih415_reset_driver);
+}
+arch_initcall(stih415_reset_init);
diff --git a/include/dt-bindings/reset-controller/stih415-resets.h b/include/dt-bindings/reset-controller/stih415-resets.h
new file mode 100644
index 0000000..2d54e68
--- /dev/null
+++ b/include/dt-bindings/reset-controller/stih415-resets.h
@@ -0,0 +1,19 @@
+/*
+ * This header provides constants for the reset controller
+ * based peripheral powerdown requests on the STMicroelectronics
+ * STiH415 SoC.
+ */
+#ifndef _DT_BINDINGS_RESET_CONTROLLER_STIH415
+#define _DT_BINDINGS_RESET_CONTROLLER_STIH415
+
+#define STIH415_EMISS_POWERDOWN 0
+#define STIH415_NAND_POWERDOWN 1
+#define STIH415_KEYSCAN_POWERDOWN 2
+#define STIH415_USB0_POWERDOWN 3
+#define STIH415_USB1_POWERDOWN 4
+#define STIH415_USB2_POWERDOWN 5
+#define STIH415_SATA0_POWERDOWN 6
+#define STIH415_SATA1_POWERDOWN 7
+#define STIH415_PCIE_POWERDOWN 8
+
+#endif /* _DT_BINDINGS_RESET_CONTROLLER_STIH415 */
--
1.7.9.5
^ permalink raw reply related [flat|nested] 72+ messages in thread
* [PATCH v2 3/6] drivers: reset: Reset controller driver for STiH416
@ 2014-02-03 14:28 ` srinivas.kandagatla-qxv4g6HH51o
0 siblings, 0 replies; 72+ messages in thread
From: srinivas.kandagatla @ 2014-02-03 14:28 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Philipp Zabel, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Rob Landley, Russell King,
Srinivas Kandagatla, Stuart Menefy, Grant Likely, devicetree,
linux-doc, linux-kernel, kernel, Arnd Bergmann,
stephen.gallimore, Olof Johansson
From: Stephen Gallimore <stephen.gallimore@st.com>
This patch adds a reset controller platform driver for the STiH416
SoC. This initial version provides a compatible driver for the
"st,stih416-powerdown" device, which registers a system configuration
register based reset controller that controls the powerdown state of
hardware such as the on-chip USB host controllers.
Signed-off-by: Stephen Gallimore <stephen.gallimore@st.com>
---
arch/arm/boot/dts/stih416.dtsi | 6 ++
drivers/reset/sti/Kconfig | 4 +
drivers/reset/sti/Makefile | 2 +-
drivers/reset/sti/reset-stih416.c | 79 ++++++++++++++++++++
.../dt-bindings/reset-controller/stih416-resets.h | 21 ++++++
5 files changed, 111 insertions(+), 1 deletion(-)
create mode 100644 drivers/reset/sti/reset-stih416.c
create mode 100644 include/dt-bindings/reset-controller/stih416-resets.h
diff --git a/arch/arm/boot/dts/stih416.dtsi b/arch/arm/boot/dts/stih416.dtsi
index b7ab47b..e5bec66 100644
--- a/arch/arm/boot/dts/stih416.dtsi
+++ b/arch/arm/boot/dts/stih416.dtsi
@@ -10,6 +10,7 @@
#include "stih416-clock.dtsi"
#include "stih416-pinctrl.dtsi"
#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/reset-controller/stih416-resets.h>
/ {
L2: cache-controller {
compatible = "arm,pl310-cache";
@@ -27,6 +28,11 @@
ranges;
compatible = "simple-bus";
+ powerdown: powerdown-controller {
+ #reset-cells = <1>;
+ compatible = "st,stih416-powerdown";
+ };
+
syscfg_sbc:sbc-syscfg@fe600000{
compatible = "st,stih416-sbc-syscfg", "syscon";
reg = <0xfe600000 0x1000>;
diff --git a/drivers/reset/sti/Kconfig b/drivers/reset/sti/Kconfig
index ef6654a..88d2d03 100644
--- a/drivers/reset/sti/Kconfig
+++ b/drivers/reset/sti/Kconfig
@@ -8,4 +8,8 @@ config STIH415_RESET
bool
select STI_RESET_SYSCFG
+config STIH416_RESET
+ bool
+ select STI_RESET_SYSCFG
+
endif
diff --git a/drivers/reset/sti/Makefile b/drivers/reset/sti/Makefile
index fce4433..be1c976 100644
--- a/drivers/reset/sti/Makefile
+++ b/drivers/reset/sti/Makefile
@@ -1,4 +1,4 @@
obj-$(CONFIG_STI_RESET_SYSCFG) += reset-syscfg.o
-# SoC specific reset devices
obj-$(CONFIG_STIH415_RESET) += reset-stih415.o
+obj-$(CONFIG_STIH416_RESET) += reset-stih416.o
diff --git a/drivers/reset/sti/reset-stih416.c b/drivers/reset/sti/reset-stih416.c
new file mode 100644
index 0000000..0becfc5
--- /dev/null
+++ b/drivers/reset/sti/reset-stih416.c
@@ -0,0 +1,79 @@
+/*
+ * Copyright (C) 2013 STMicroelectronics (R&D) Limited
+ * Author: Stephen Gallimore <stephen.gallimore@st.com>
+ * Author: Srinivas Kandagatla <srinivas.kandagatla@st.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+
+#include <dt-bindings/reset-controller/stih416-resets.h>
+
+#include "reset-syscfg.h"
+
+/*
+ * STiH416 Peripheral powerdown definitions.
+ */
+static const char stih416_front[] = "st,stih416-front-syscfg";
+static const char stih416_rear[] = "st,stih416-rear-syscfg";
+static const char stih416_sbc[] = "st,stih416-sbc-syscfg";
+static const char stih416_lpm[] = "st,stih416-lpm-syscfg";
+
+#define STIH416_PDN_FRONT(_bit) \
+ _SYSCFG_RST_CH(stih416_front, SYSCFG_1500, _bit, SYSSTAT_1578, _bit)
+
+#define STIH416_PDN_REAR(_cntl, _stat) \
+ _SYSCFG_RST_CH(stih416_rear, SYSCFG_2525, _cntl, SYSSTAT_2583, _stat)
+
+#define SYSCFG_1500 0x7d0 /* Powerdown request EMI/NAND/Keyscan */
+#define SYSSTAT_1578 0x908 /* Powerdown status EMI/NAND/Keyscan */
+
+#define SYSCFG_2525 0x834 /* Powerdown request USB/SATA/PCIe */
+#define SYSSTAT_2583 0x91c /* Powerdown status USB/SATA/PCIe */
+
+static const struct syscfg_reset_channel_data stih416_powerdowns[] = {
+ [STIH416_EMISS_POWERDOWN] = STIH416_PDN_FRONT(0),
+ [STIH416_NAND_POWERDOWN] = STIH416_PDN_FRONT(1),
+ [STIH416_KEYSCAN_POWERDOWN] = STIH416_PDN_FRONT(2),
+ [STIH416_USB0_POWERDOWN] = STIH416_PDN_REAR(0, 0),
+ [STIH416_USB1_POWERDOWN] = STIH416_PDN_REAR(1, 1),
+ [STIH416_USB2_POWERDOWN] = STIH416_PDN_REAR(2, 2),
+ [STIH416_USB3_POWERDOWN] = STIH416_PDN_REAR(6, 5),
+ [STIH416_SATA0_POWERDOWN] = STIH416_PDN_REAR(3, 3),
+ [STIH416_SATA1_POWERDOWN] = STIH416_PDN_REAR(4, 4),
+ [STIH416_PCIE0_POWERDOWN] = STIH416_PDN_REAR(7, 9),
+ [STIH416_PCIE1_POWERDOWN] = STIH416_PDN_REAR(5, 8),
+};
+
+static struct syscfg_reset_controller_data stih416_powerdown_controller = {
+ .wait_for_ack = true,
+ .nr_channels = ARRAY_SIZE(stih416_powerdowns),
+ .channels = stih416_powerdowns,
+};
+
+static struct of_device_id stih416_reset_match[] = {
+ { .compatible = "st,stih416-powerdown",
+ .data = &stih416_powerdown_controller, },
+ {},
+};
+
+static struct platform_driver stih416_reset_driver = {
+ .probe = syscfg_reset_probe,
+ .driver = {
+ .name = "reset-stih416",
+ .owner = THIS_MODULE,
+ .of_match_table = stih416_reset_match,
+ },
+};
+
+static int __init stih416_reset_init(void)
+{
+ return platform_driver_register(&stih416_reset_driver);
+}
+arch_initcall(stih416_reset_init);
diff --git a/include/dt-bindings/reset-controller/stih416-resets.h b/include/dt-bindings/reset-controller/stih416-resets.h
new file mode 100644
index 0000000..d7da55f
--- /dev/null
+++ b/include/dt-bindings/reset-controller/stih416-resets.h
@@ -0,0 +1,21 @@
+/*
+ * This header provides constants for the reset controller
+ * based peripheral powerdown requests on the STMicroelectronics
+ * STiH416 SoC.
+ */
+#ifndef _DT_BINDINGS_RESET_CONTROLLER_STIH416
+#define _DT_BINDINGS_RESET_CONTROLLER_STIH416
+
+#define STIH416_EMISS_POWERDOWN 0
+#define STIH416_NAND_POWERDOWN 1
+#define STIH416_KEYSCAN_POWERDOWN 2
+#define STIH416_USB0_POWERDOWN 3
+#define STIH416_USB1_POWERDOWN 4
+#define STIH416_USB2_POWERDOWN 5
+#define STIH416_USB3_POWERDOWN 6
+#define STIH416_SATA0_POWERDOWN 7
+#define STIH416_SATA1_POWERDOWN 8
+#define STIH416_PCIE0_POWERDOWN 9
+#define STIH416_PCIE1_POWERDOWN 10
+
+#endif /* _DT_BINDINGS_RESET_CONTROLLER_STIH416 */
--
1.7.9.5
^ permalink raw reply related [flat|nested] 72+ messages in thread* [PATCH v2 3/6] drivers: reset: Reset controller driver for STiH416
@ 2014-02-03 14:28 ` srinivas.kandagatla-qxv4g6HH51o
0 siblings, 0 replies; 72+ messages in thread
From: srinivas.kandagatla at st.com @ 2014-02-03 14:28 UTC (permalink / raw)
To: linux-arm-kernel
From: Stephen Gallimore <stephen.gallimore@st.com>
This patch adds a reset controller platform driver for the STiH416
SoC. This initial version provides a compatible driver for the
"st,stih416-powerdown" device, which registers a system configuration
register based reset controller that controls the powerdown state of
hardware such as the on-chip USB host controllers.
Signed-off-by: Stephen Gallimore <stephen.gallimore@st.com>
---
arch/arm/boot/dts/stih416.dtsi | 6 ++
drivers/reset/sti/Kconfig | 4 +
drivers/reset/sti/Makefile | 2 +-
drivers/reset/sti/reset-stih416.c | 79 ++++++++++++++++++++
.../dt-bindings/reset-controller/stih416-resets.h | 21 ++++++
5 files changed, 111 insertions(+), 1 deletion(-)
create mode 100644 drivers/reset/sti/reset-stih416.c
create mode 100644 include/dt-bindings/reset-controller/stih416-resets.h
diff --git a/arch/arm/boot/dts/stih416.dtsi b/arch/arm/boot/dts/stih416.dtsi
index b7ab47b..e5bec66 100644
--- a/arch/arm/boot/dts/stih416.dtsi
+++ b/arch/arm/boot/dts/stih416.dtsi
@@ -10,6 +10,7 @@
#include "stih416-clock.dtsi"
#include "stih416-pinctrl.dtsi"
#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/reset-controller/stih416-resets.h>
/ {
L2: cache-controller {
compatible = "arm,pl310-cache";
@@ -27,6 +28,11 @@
ranges;
compatible = "simple-bus";
+ powerdown: powerdown-controller {
+ #reset-cells = <1>;
+ compatible = "st,stih416-powerdown";
+ };
+
syscfg_sbc:sbc-syscfg at fe600000{
compatible = "st,stih416-sbc-syscfg", "syscon";
reg = <0xfe600000 0x1000>;
diff --git a/drivers/reset/sti/Kconfig b/drivers/reset/sti/Kconfig
index ef6654a..88d2d03 100644
--- a/drivers/reset/sti/Kconfig
+++ b/drivers/reset/sti/Kconfig
@@ -8,4 +8,8 @@ config STIH415_RESET
bool
select STI_RESET_SYSCFG
+config STIH416_RESET
+ bool
+ select STI_RESET_SYSCFG
+
endif
diff --git a/drivers/reset/sti/Makefile b/drivers/reset/sti/Makefile
index fce4433..be1c976 100644
--- a/drivers/reset/sti/Makefile
+++ b/drivers/reset/sti/Makefile
@@ -1,4 +1,4 @@
obj-$(CONFIG_STI_RESET_SYSCFG) += reset-syscfg.o
-# SoC specific reset devices
obj-$(CONFIG_STIH415_RESET) += reset-stih415.o
+obj-$(CONFIG_STIH416_RESET) += reset-stih416.o
diff --git a/drivers/reset/sti/reset-stih416.c b/drivers/reset/sti/reset-stih416.c
new file mode 100644
index 0000000..0becfc5
--- /dev/null
+++ b/drivers/reset/sti/reset-stih416.c
@@ -0,0 +1,79 @@
+/*
+ * Copyright (C) 2013 STMicroelectronics (R&D) Limited
+ * Author: Stephen Gallimore <stephen.gallimore@st.com>
+ * Author: Srinivas Kandagatla <srinivas.kandagatla@st.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+
+#include <dt-bindings/reset-controller/stih416-resets.h>
+
+#include "reset-syscfg.h"
+
+/*
+ * STiH416 Peripheral powerdown definitions.
+ */
+static const char stih416_front[] = "st,stih416-front-syscfg";
+static const char stih416_rear[] = "st,stih416-rear-syscfg";
+static const char stih416_sbc[] = "st,stih416-sbc-syscfg";
+static const char stih416_lpm[] = "st,stih416-lpm-syscfg";
+
+#define STIH416_PDN_FRONT(_bit) \
+ _SYSCFG_RST_CH(stih416_front, SYSCFG_1500, _bit, SYSSTAT_1578, _bit)
+
+#define STIH416_PDN_REAR(_cntl, _stat) \
+ _SYSCFG_RST_CH(stih416_rear, SYSCFG_2525, _cntl, SYSSTAT_2583, _stat)
+
+#define SYSCFG_1500 0x7d0 /* Powerdown request EMI/NAND/Keyscan */
+#define SYSSTAT_1578 0x908 /* Powerdown status EMI/NAND/Keyscan */
+
+#define SYSCFG_2525 0x834 /* Powerdown request USB/SATA/PCIe */
+#define SYSSTAT_2583 0x91c /* Powerdown status USB/SATA/PCIe */
+
+static const struct syscfg_reset_channel_data stih416_powerdowns[] = {
+ [STIH416_EMISS_POWERDOWN] = STIH416_PDN_FRONT(0),
+ [STIH416_NAND_POWERDOWN] = STIH416_PDN_FRONT(1),
+ [STIH416_KEYSCAN_POWERDOWN] = STIH416_PDN_FRONT(2),
+ [STIH416_USB0_POWERDOWN] = STIH416_PDN_REAR(0, 0),
+ [STIH416_USB1_POWERDOWN] = STIH416_PDN_REAR(1, 1),
+ [STIH416_USB2_POWERDOWN] = STIH416_PDN_REAR(2, 2),
+ [STIH416_USB3_POWERDOWN] = STIH416_PDN_REAR(6, 5),
+ [STIH416_SATA0_POWERDOWN] = STIH416_PDN_REAR(3, 3),
+ [STIH416_SATA1_POWERDOWN] = STIH416_PDN_REAR(4, 4),
+ [STIH416_PCIE0_POWERDOWN] = STIH416_PDN_REAR(7, 9),
+ [STIH416_PCIE1_POWERDOWN] = STIH416_PDN_REAR(5, 8),
+};
+
+static struct syscfg_reset_controller_data stih416_powerdown_controller = {
+ .wait_for_ack = true,
+ .nr_channels = ARRAY_SIZE(stih416_powerdowns),
+ .channels = stih416_powerdowns,
+};
+
+static struct of_device_id stih416_reset_match[] = {
+ { .compatible = "st,stih416-powerdown",
+ .data = &stih416_powerdown_controller, },
+ {},
+};
+
+static struct platform_driver stih416_reset_driver = {
+ .probe = syscfg_reset_probe,
+ .driver = {
+ .name = "reset-stih416",
+ .owner = THIS_MODULE,
+ .of_match_table = stih416_reset_match,
+ },
+};
+
+static int __init stih416_reset_init(void)
+{
+ return platform_driver_register(&stih416_reset_driver);
+}
+arch_initcall(stih416_reset_init);
diff --git a/include/dt-bindings/reset-controller/stih416-resets.h b/include/dt-bindings/reset-controller/stih416-resets.h
new file mode 100644
index 0000000..d7da55f
--- /dev/null
+++ b/include/dt-bindings/reset-controller/stih416-resets.h
@@ -0,0 +1,21 @@
+/*
+ * This header provides constants for the reset controller
+ * based peripheral powerdown requests on the STMicroelectronics
+ * STiH416 SoC.
+ */
+#ifndef _DT_BINDINGS_RESET_CONTROLLER_STIH416
+#define _DT_BINDINGS_RESET_CONTROLLER_STIH416
+
+#define STIH416_EMISS_POWERDOWN 0
+#define STIH416_NAND_POWERDOWN 1
+#define STIH416_KEYSCAN_POWERDOWN 2
+#define STIH416_USB0_POWERDOWN 3
+#define STIH416_USB1_POWERDOWN 4
+#define STIH416_USB2_POWERDOWN 5
+#define STIH416_USB3_POWERDOWN 6
+#define STIH416_SATA0_POWERDOWN 7
+#define STIH416_SATA1_POWERDOWN 8
+#define STIH416_PCIE0_POWERDOWN 9
+#define STIH416_PCIE1_POWERDOWN 10
+
+#endif /* _DT_BINDINGS_RESET_CONTROLLER_STIH416 */
--
1.7.9.5
^ permalink raw reply related [flat|nested] 72+ messages in thread* [PATCH v2 3/6] drivers: reset: Reset controller driver for STiH416
@ 2014-02-03 14:28 ` srinivas.kandagatla-qxv4g6HH51o
0 siblings, 0 replies; 72+ messages in thread
From: srinivas.kandagatla-qxv4g6HH51o @ 2014-02-03 14:28 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Philipp Zabel, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Rob Landley, Russell King,
Srinivas Kandagatla, Stuart Menefy, Grant Likely,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-F5mvAk5X5gdBDgjK7y7TUQ, Arnd Bergmann,
stephen.gallimore-qxv4g6HH51o, Olof Johansson
From: Stephen Gallimore <stephen.gallimore-qxv4g6HH51o@public.gmane.org>
This patch adds a reset controller platform driver for the STiH416
SoC. This initial version provides a compatible driver for the
"st,stih416-powerdown" device, which registers a system configuration
register based reset controller that controls the powerdown state of
hardware such as the on-chip USB host controllers.
Signed-off-by: Stephen Gallimore <stephen.gallimore-qxv4g6HH51o@public.gmane.org>
---
arch/arm/boot/dts/stih416.dtsi | 6 ++
drivers/reset/sti/Kconfig | 4 +
drivers/reset/sti/Makefile | 2 +-
drivers/reset/sti/reset-stih416.c | 79 ++++++++++++++++++++
.../dt-bindings/reset-controller/stih416-resets.h | 21 ++++++
5 files changed, 111 insertions(+), 1 deletion(-)
create mode 100644 drivers/reset/sti/reset-stih416.c
create mode 100644 include/dt-bindings/reset-controller/stih416-resets.h
diff --git a/arch/arm/boot/dts/stih416.dtsi b/arch/arm/boot/dts/stih416.dtsi
index b7ab47b..e5bec66 100644
--- a/arch/arm/boot/dts/stih416.dtsi
+++ b/arch/arm/boot/dts/stih416.dtsi
@@ -10,6 +10,7 @@
#include "stih416-clock.dtsi"
#include "stih416-pinctrl.dtsi"
#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/reset-controller/stih416-resets.h>
/ {
L2: cache-controller {
compatible = "arm,pl310-cache";
@@ -27,6 +28,11 @@
ranges;
compatible = "simple-bus";
+ powerdown: powerdown-controller {
+ #reset-cells = <1>;
+ compatible = "st,stih416-powerdown";
+ };
+
syscfg_sbc:sbc-syscfg@fe600000{
compatible = "st,stih416-sbc-syscfg", "syscon";
reg = <0xfe600000 0x1000>;
diff --git a/drivers/reset/sti/Kconfig b/drivers/reset/sti/Kconfig
index ef6654a..88d2d03 100644
--- a/drivers/reset/sti/Kconfig
+++ b/drivers/reset/sti/Kconfig
@@ -8,4 +8,8 @@ config STIH415_RESET
bool
select STI_RESET_SYSCFG
+config STIH416_RESET
+ bool
+ select STI_RESET_SYSCFG
+
endif
diff --git a/drivers/reset/sti/Makefile b/drivers/reset/sti/Makefile
index fce4433..be1c976 100644
--- a/drivers/reset/sti/Makefile
+++ b/drivers/reset/sti/Makefile
@@ -1,4 +1,4 @@
obj-$(CONFIG_STI_RESET_SYSCFG) += reset-syscfg.o
-# SoC specific reset devices
obj-$(CONFIG_STIH415_RESET) += reset-stih415.o
+obj-$(CONFIG_STIH416_RESET) += reset-stih416.o
diff --git a/drivers/reset/sti/reset-stih416.c b/drivers/reset/sti/reset-stih416.c
new file mode 100644
index 0000000..0becfc5
--- /dev/null
+++ b/drivers/reset/sti/reset-stih416.c
@@ -0,0 +1,79 @@
+/*
+ * Copyright (C) 2013 STMicroelectronics (R&D) Limited
+ * Author: Stephen Gallimore <stephen.gallimore-qxv4g6HH51o@public.gmane.org>
+ * Author: Srinivas Kandagatla <srinivas.kandagatla-qxv4g6HH51o@public.gmane.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+
+#include <dt-bindings/reset-controller/stih416-resets.h>
+
+#include "reset-syscfg.h"
+
+/*
+ * STiH416 Peripheral powerdown definitions.
+ */
+static const char stih416_front[] = "st,stih416-front-syscfg";
+static const char stih416_rear[] = "st,stih416-rear-syscfg";
+static const char stih416_sbc[] = "st,stih416-sbc-syscfg";
+static const char stih416_lpm[] = "st,stih416-lpm-syscfg";
+
+#define STIH416_PDN_FRONT(_bit) \
+ _SYSCFG_RST_CH(stih416_front, SYSCFG_1500, _bit, SYSSTAT_1578, _bit)
+
+#define STIH416_PDN_REAR(_cntl, _stat) \
+ _SYSCFG_RST_CH(stih416_rear, SYSCFG_2525, _cntl, SYSSTAT_2583, _stat)
+
+#define SYSCFG_1500 0x7d0 /* Powerdown request EMI/NAND/Keyscan */
+#define SYSSTAT_1578 0x908 /* Powerdown status EMI/NAND/Keyscan */
+
+#define SYSCFG_2525 0x834 /* Powerdown request USB/SATA/PCIe */
+#define SYSSTAT_2583 0x91c /* Powerdown status USB/SATA/PCIe */
+
+static const struct syscfg_reset_channel_data stih416_powerdowns[] = {
+ [STIH416_EMISS_POWERDOWN] = STIH416_PDN_FRONT(0),
+ [STIH416_NAND_POWERDOWN] = STIH416_PDN_FRONT(1),
+ [STIH416_KEYSCAN_POWERDOWN] = STIH416_PDN_FRONT(2),
+ [STIH416_USB0_POWERDOWN] = STIH416_PDN_REAR(0, 0),
+ [STIH416_USB1_POWERDOWN] = STIH416_PDN_REAR(1, 1),
+ [STIH416_USB2_POWERDOWN] = STIH416_PDN_REAR(2, 2),
+ [STIH416_USB3_POWERDOWN] = STIH416_PDN_REAR(6, 5),
+ [STIH416_SATA0_POWERDOWN] = STIH416_PDN_REAR(3, 3),
+ [STIH416_SATA1_POWERDOWN] = STIH416_PDN_REAR(4, 4),
+ [STIH416_PCIE0_POWERDOWN] = STIH416_PDN_REAR(7, 9),
+ [STIH416_PCIE1_POWERDOWN] = STIH416_PDN_REAR(5, 8),
+};
+
+static struct syscfg_reset_controller_data stih416_powerdown_controller = {
+ .wait_for_ack = true,
+ .nr_channels = ARRAY_SIZE(stih416_powerdowns),
+ .channels = stih416_powerdowns,
+};
+
+static struct of_device_id stih416_reset_match[] = {
+ { .compatible = "st,stih416-powerdown",
+ .data = &stih416_powerdown_controller, },
+ {},
+};
+
+static struct platform_driver stih416_reset_driver = {
+ .probe = syscfg_reset_probe,
+ .driver = {
+ .name = "reset-stih416",
+ .owner = THIS_MODULE,
+ .of_match_table = stih416_reset_match,
+ },
+};
+
+static int __init stih416_reset_init(void)
+{
+ return platform_driver_register(&stih416_reset_driver);
+}
+arch_initcall(stih416_reset_init);
diff --git a/include/dt-bindings/reset-controller/stih416-resets.h b/include/dt-bindings/reset-controller/stih416-resets.h
new file mode 100644
index 0000000..d7da55f
--- /dev/null
+++ b/include/dt-bindings/reset-controller/stih416-resets.h
@@ -0,0 +1,21 @@
+/*
+ * This header provides constants for the reset controller
+ * based peripheral powerdown requests on the STMicroelectronics
+ * STiH416 SoC.
+ */
+#ifndef _DT_BINDINGS_RESET_CONTROLLER_STIH416
+#define _DT_BINDINGS_RESET_CONTROLLER_STIH416
+
+#define STIH416_EMISS_POWERDOWN 0
+#define STIH416_NAND_POWERDOWN 1
+#define STIH416_KEYSCAN_POWERDOWN 2
+#define STIH416_USB0_POWERDOWN 3
+#define STIH416_USB1_POWERDOWN 4
+#define STIH416_USB2_POWERDOWN 5
+#define STIH416_USB3_POWERDOWN 6
+#define STIH416_SATA0_POWERDOWN 7
+#define STIH416_SATA1_POWERDOWN 8
+#define STIH416_PCIE0_POWERDOWN 9
+#define STIH416_PCIE1_POWERDOWN 10
+
+#endif /* _DT_BINDINGS_RESET_CONTROLLER_STIH416 */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 72+ messages in thread
* [PATCH v2 4/6] drivers: reset: stih415: add softreset controller
@ 2014-02-03 14:28 ` srinivas.kandagatla-qxv4g6HH51o
0 siblings, 0 replies; 72+ messages in thread
From: srinivas.kandagatla @ 2014-02-03 14:28 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Philipp Zabel, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Rob Landley, Russell King,
Srinivas Kandagatla, Stuart Menefy, Grant Likely, devicetree,
linux-doc, linux-kernel, kernel, Arnd Bergmann,
stephen.gallimore, Olof Johansson
From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
This patch adds softreset controller for STiH415 SOC, soft reset
controller is based on system configuration registers which are mapped
via regmap. This reset controller does not have any feedback or
acknowledgement. With this patch a new device "st,stih415-softreset" is
registered with system configuration registers based reset controller
that controls the softreset state of the hardware such as Ethernet, IRB.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
---
.../devicetree/bindings/reset/st,sti-softreset.txt | 46 ++++++++++++++++++++
arch/arm/boot/dts/stih415.dtsi | 5 +++
drivers/reset/sti/reset-stih415.c | 35 +++++++++++++++
.../dt-bindings/reset-controller/stih415-resets.h | 7 +++
4 files changed, 93 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reset/st,sti-softreset.txt
diff --git a/Documentation/devicetree/bindings/reset/st,sti-softreset.txt b/Documentation/devicetree/bindings/reset/st,sti-softreset.txt
new file mode 100644
index 0000000..a8d3d3c
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/st,sti-softreset.txt
@@ -0,0 +1,46 @@
+STMicroelectronics STi family Sysconfig Peripheral SoftReset Controller
+=============================================================================
+
+This binding describes a reset controller device that is used to enable and
+disable on-chip peripheral controllers such as USB and SATA, using
+"softreset" control bits found in the STi family SoC system configuration
+registers.
+
+The actual action taken when softreset is asserted is hardware dependent.
+However, when asserted it may not be possible to access the hardware's
+registers and after an assert/deassert sequence the hardware's previous state
+may no longer be valid.
+
+Please refer to reset.txt in this directory for common reset
+controller binding usage.
+
+Required properties:
+- compatible: Should be "st,<chip>-softreset" example:
+ "st,stih415-softreset" or "st,stih416-softreset";
+- #reset-cells: 1, see below
+
+example:
+
+ softreset: softreset-controller {
+ #reset-cells = <1>;
+ compatible = "st,stih415-softreset";
+ };
+
+
+Specifying softreset control of devices
+=======================================
+
+Device nodes should specify the reset channel required in their "resets"
+property, containing a phandle to the softreset device node and an
+index specifying which channel to use, as described in reset.txt
+
+example:
+
+ ethernet0{
+ resets = <&softreset STIH415_ETH0_SOFTRESET>;
+ };
+
+Macro definitions for the supported reset channels can be found in:
+
+include/dt-bindings/reset-controller/stih415-resets.h
+include/dt-bindings/reset-controller/stih416-resets.h
diff --git a/arch/arm/boot/dts/stih415.dtsi b/arch/arm/boot/dts/stih415.dtsi
index 19e29f4..d52207c 100644
--- a/arch/arm/boot/dts/stih415.dtsi
+++ b/arch/arm/boot/dts/stih415.dtsi
@@ -34,6 +34,11 @@
compatible = "st,stih415-powerdown";
};
+ softreset: softreset-controller {
+ #reset-cells = <1>;
+ compatible = "st,stih415-softreset";
+ };
+
syscfg_sbc: sbc-syscfg@fe600000{
compatible = "st,stih415-sbc-syscfg", "syscon";
reg = <0xfe600000 0xb4>;
diff --git a/drivers/reset/sti/reset-stih415.c b/drivers/reset/sti/reset-stih415.c
index 56c2146..e6f6c41 100644
--- a/drivers/reset/sti/reset-stih415.c
+++ b/drivers/reset/sti/reset-stih415.c
@@ -31,12 +31,29 @@ static const char stih415_lpm[] = "st,stih415-lpm-syscfg";
#define STIH415_PDN_REAR(_cntl, _stat) \
_SYSCFG_RST_CH(stih415_rear, SYSCFG_336, _cntl, SYSSTAT_384, _stat)
+#define STIH415_SRST_REAR(_reg, _bit) \
+ _SYSCFG_RST_CH_NO_ACK(stih415_rear, _reg, _bit)
+
+#define STIH415_SRST_SBC(_reg, _bit) \
+ _SYSCFG_RST_CH_NO_ACK(stih415_sbc, _reg, _bit)
+
+#define STIH415_SRST_FRONT(_reg, _bit) \
+ _SYSCFG_RST_CH_NO_ACK(stih415_front, _reg, _bit)
+
+#define STIH415_SRST_LPM(_reg, _bit) \
+ _SYSCFG_RST_CH_NO_ACK(stih415_lpm, _reg, _bit)
+
#define SYSCFG_114 0x38 /* Powerdown request EMI/NAND/Keyscan */
#define SYSSTAT_187 0x15c /* Powerdown status EMI/NAND/Keyscan */
#define SYSCFG_336 0x90 /* Powerdown request USB/SATA/PCIe */
#define SYSSTAT_384 0x150 /* Powerdown status USB/SATA/PCIe */
+#define SYSCFG_376 0x130 /* Reset generator 0 control 0 */
+#define SYSCFG_166 0x108 /* Softreset Ethernet 0 */
+#define SYSCFG_31 0x7c /* Softreset Ethernet 1 */
+#define LPM_SYSCFG_1 0x4 /* Softreset IRB */
+
static const struct syscfg_reset_channel_data stih415_powerdowns[] = {
[STIH415_EMISS_POWERDOWN] = STIH415_PDN_FRONT(0),
[STIH415_NAND_POWERDOWN] = STIH415_PDN_FRONT(1),
@@ -49,15 +66,33 @@ static const struct syscfg_reset_channel_data stih415_powerdowns[] = {
[STIH415_PCIE_POWERDOWN] = STIH415_PDN_REAR(5, 8),
};
+static const struct syscfg_reset_channel_data stih415_softresets[] = {
+ [STIH415_ETH0_SOFTRESET] = STIH415_SRST_FRONT(SYSCFG_166, 0),
+ [STIH415_ETH1_SOFTRESET] = STIH415_SRST_SBC(SYSCFG_31, 0),
+ [STIH415_IRB_SOFTRESET] = STIH415_SRST_LPM(LPM_SYSCFG_1, 6),
+ [STIH415_USB0_SOFTRESET] = STIH415_SRST_REAR(SYSCFG_376, 9),
+ [STIH415_USB1_SOFTRESET] = STIH415_SRST_REAR(SYSCFG_376, 10),
+ [STIH415_USB2_SOFTRESET] = STIH415_SRST_REAR(SYSCFG_376, 11),
+};
+
static struct syscfg_reset_controller_data stih415_powerdown_controller = {
.wait_for_ack = true,
.nr_channels = ARRAY_SIZE(stih415_powerdowns),
.channels = stih415_powerdowns,
};
+static struct syscfg_reset_controller_data stih415_softreset_controller = {
+ .wait_for_ack = false,
+ .active_low = true,
+ .nr_channels = ARRAY_SIZE(stih415_softresets),
+ .channels = stih415_softresets,
+};
+
static struct of_device_id stih415_reset_match[] = {
{ .compatible = "st,stih415-powerdown",
.data = &stih415_powerdown_controller, },
+ { .compatible = "st,stih415-softreset",
+ .data = &stih415_softreset_controller, },
{},
};
diff --git a/include/dt-bindings/reset-controller/stih415-resets.h b/include/dt-bindings/reset-controller/stih415-resets.h
index 2d54e68..c2f8a66 100644
--- a/include/dt-bindings/reset-controller/stih415-resets.h
+++ b/include/dt-bindings/reset-controller/stih415-resets.h
@@ -16,4 +16,11 @@
#define STIH415_SATA1_POWERDOWN 7
#define STIH415_PCIE_POWERDOWN 8
+#define STIH415_ETH0_SOFTRESET 0
+#define STIH415_ETH1_SOFTRESET 1
+#define STIH415_IRB_SOFTRESET 2
+#define STIH415_USB0_SOFTRESET 3
+#define STIH415_USB1_SOFTRESET 4
+#define STIH415_USB2_SOFTRESET 5
+
#endif /* _DT_BINDINGS_RESET_CONTROLLER_STIH415 */
--
1.7.9.5
^ permalink raw reply related [flat|nested] 72+ messages in thread* [PATCH v2 4/6] drivers: reset: stih415: add softreset controller
@ 2014-02-03 14:28 ` srinivas.kandagatla-qxv4g6HH51o
0 siblings, 0 replies; 72+ messages in thread
From: srinivas.kandagatla at st.com @ 2014-02-03 14:28 UTC (permalink / raw)
To: linux-arm-kernel
From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
This patch adds softreset controller for STiH415 SOC, soft reset
controller is based on system configuration registers which are mapped
via regmap. This reset controller does not have any feedback or
acknowledgement. With this patch a new device "st,stih415-softreset" is
registered with system configuration registers based reset controller
that controls the softreset state of the hardware such as Ethernet, IRB.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
---
.../devicetree/bindings/reset/st,sti-softreset.txt | 46 ++++++++++++++++++++
arch/arm/boot/dts/stih415.dtsi | 5 +++
drivers/reset/sti/reset-stih415.c | 35 +++++++++++++++
.../dt-bindings/reset-controller/stih415-resets.h | 7 +++
4 files changed, 93 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reset/st,sti-softreset.txt
diff --git a/Documentation/devicetree/bindings/reset/st,sti-softreset.txt b/Documentation/devicetree/bindings/reset/st,sti-softreset.txt
new file mode 100644
index 0000000..a8d3d3c
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/st,sti-softreset.txt
@@ -0,0 +1,46 @@
+STMicroelectronics STi family Sysconfig Peripheral SoftReset Controller
+=============================================================================
+
+This binding describes a reset controller device that is used to enable and
+disable on-chip peripheral controllers such as USB and SATA, using
+"softreset" control bits found in the STi family SoC system configuration
+registers.
+
+The actual action taken when softreset is asserted is hardware dependent.
+However, when asserted it may not be possible to access the hardware's
+registers and after an assert/deassert sequence the hardware's previous state
+may no longer be valid.
+
+Please refer to reset.txt in this directory for common reset
+controller binding usage.
+
+Required properties:
+- compatible: Should be "st,<chip>-softreset" example:
+ "st,stih415-softreset" or "st,stih416-softreset";
+- #reset-cells: 1, see below
+
+example:
+
+ softreset: softreset-controller {
+ #reset-cells = <1>;
+ compatible = "st,stih415-softreset";
+ };
+
+
+Specifying softreset control of devices
+=======================================
+
+Device nodes should specify the reset channel required in their "resets"
+property, containing a phandle to the softreset device node and an
+index specifying which channel to use, as described in reset.txt
+
+example:
+
+ ethernet0{
+ resets = <&softreset STIH415_ETH0_SOFTRESET>;
+ };
+
+Macro definitions for the supported reset channels can be found in:
+
+include/dt-bindings/reset-controller/stih415-resets.h
+include/dt-bindings/reset-controller/stih416-resets.h
diff --git a/arch/arm/boot/dts/stih415.dtsi b/arch/arm/boot/dts/stih415.dtsi
index 19e29f4..d52207c 100644
--- a/arch/arm/boot/dts/stih415.dtsi
+++ b/arch/arm/boot/dts/stih415.dtsi
@@ -34,6 +34,11 @@
compatible = "st,stih415-powerdown";
};
+ softreset: softreset-controller {
+ #reset-cells = <1>;
+ compatible = "st,stih415-softreset";
+ };
+
syscfg_sbc: sbc-syscfg at fe600000{
compatible = "st,stih415-sbc-syscfg", "syscon";
reg = <0xfe600000 0xb4>;
diff --git a/drivers/reset/sti/reset-stih415.c b/drivers/reset/sti/reset-stih415.c
index 56c2146..e6f6c41 100644
--- a/drivers/reset/sti/reset-stih415.c
+++ b/drivers/reset/sti/reset-stih415.c
@@ -31,12 +31,29 @@ static const char stih415_lpm[] = "st,stih415-lpm-syscfg";
#define STIH415_PDN_REAR(_cntl, _stat) \
_SYSCFG_RST_CH(stih415_rear, SYSCFG_336, _cntl, SYSSTAT_384, _stat)
+#define STIH415_SRST_REAR(_reg, _bit) \
+ _SYSCFG_RST_CH_NO_ACK(stih415_rear, _reg, _bit)
+
+#define STIH415_SRST_SBC(_reg, _bit) \
+ _SYSCFG_RST_CH_NO_ACK(stih415_sbc, _reg, _bit)
+
+#define STIH415_SRST_FRONT(_reg, _bit) \
+ _SYSCFG_RST_CH_NO_ACK(stih415_front, _reg, _bit)
+
+#define STIH415_SRST_LPM(_reg, _bit) \
+ _SYSCFG_RST_CH_NO_ACK(stih415_lpm, _reg, _bit)
+
#define SYSCFG_114 0x38 /* Powerdown request EMI/NAND/Keyscan */
#define SYSSTAT_187 0x15c /* Powerdown status EMI/NAND/Keyscan */
#define SYSCFG_336 0x90 /* Powerdown request USB/SATA/PCIe */
#define SYSSTAT_384 0x150 /* Powerdown status USB/SATA/PCIe */
+#define SYSCFG_376 0x130 /* Reset generator 0 control 0 */
+#define SYSCFG_166 0x108 /* Softreset Ethernet 0 */
+#define SYSCFG_31 0x7c /* Softreset Ethernet 1 */
+#define LPM_SYSCFG_1 0x4 /* Softreset IRB */
+
static const struct syscfg_reset_channel_data stih415_powerdowns[] = {
[STIH415_EMISS_POWERDOWN] = STIH415_PDN_FRONT(0),
[STIH415_NAND_POWERDOWN] = STIH415_PDN_FRONT(1),
@@ -49,15 +66,33 @@ static const struct syscfg_reset_channel_data stih415_powerdowns[] = {
[STIH415_PCIE_POWERDOWN] = STIH415_PDN_REAR(5, 8),
};
+static const struct syscfg_reset_channel_data stih415_softresets[] = {
+ [STIH415_ETH0_SOFTRESET] = STIH415_SRST_FRONT(SYSCFG_166, 0),
+ [STIH415_ETH1_SOFTRESET] = STIH415_SRST_SBC(SYSCFG_31, 0),
+ [STIH415_IRB_SOFTRESET] = STIH415_SRST_LPM(LPM_SYSCFG_1, 6),
+ [STIH415_USB0_SOFTRESET] = STIH415_SRST_REAR(SYSCFG_376, 9),
+ [STIH415_USB1_SOFTRESET] = STIH415_SRST_REAR(SYSCFG_376, 10),
+ [STIH415_USB2_SOFTRESET] = STIH415_SRST_REAR(SYSCFG_376, 11),
+};
+
static struct syscfg_reset_controller_data stih415_powerdown_controller = {
.wait_for_ack = true,
.nr_channels = ARRAY_SIZE(stih415_powerdowns),
.channels = stih415_powerdowns,
};
+static struct syscfg_reset_controller_data stih415_softreset_controller = {
+ .wait_for_ack = false,
+ .active_low = true,
+ .nr_channels = ARRAY_SIZE(stih415_softresets),
+ .channels = stih415_softresets,
+};
+
static struct of_device_id stih415_reset_match[] = {
{ .compatible = "st,stih415-powerdown",
.data = &stih415_powerdown_controller, },
+ { .compatible = "st,stih415-softreset",
+ .data = &stih415_softreset_controller, },
{},
};
diff --git a/include/dt-bindings/reset-controller/stih415-resets.h b/include/dt-bindings/reset-controller/stih415-resets.h
index 2d54e68..c2f8a66 100644
--- a/include/dt-bindings/reset-controller/stih415-resets.h
+++ b/include/dt-bindings/reset-controller/stih415-resets.h
@@ -16,4 +16,11 @@
#define STIH415_SATA1_POWERDOWN 7
#define STIH415_PCIE_POWERDOWN 8
+#define STIH415_ETH0_SOFTRESET 0
+#define STIH415_ETH1_SOFTRESET 1
+#define STIH415_IRB_SOFTRESET 2
+#define STIH415_USB0_SOFTRESET 3
+#define STIH415_USB1_SOFTRESET 4
+#define STIH415_USB2_SOFTRESET 5
+
#endif /* _DT_BINDINGS_RESET_CONTROLLER_STIH415 */
--
1.7.9.5
^ permalink raw reply related [flat|nested] 72+ messages in thread* [PATCH v2 4/6] drivers: reset: stih415: add softreset controller
@ 2014-02-03 14:28 ` srinivas.kandagatla-qxv4g6HH51o
0 siblings, 0 replies; 72+ messages in thread
From: srinivas.kandagatla-qxv4g6HH51o @ 2014-02-03 14:28 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Philipp Zabel, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Rob Landley, Russell King,
Srinivas Kandagatla, Stuart Menefy, Grant Likely,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-F5mvAk5X5gdBDgjK7y7TUQ, Arnd Bergmann,
stephen.gallimore-qxv4g6HH51o, Olof Johansson
From: Srinivas Kandagatla <srinivas.kandagatla-qxv4g6HH51o@public.gmane.org>
This patch adds softreset controller for STiH415 SOC, soft reset
controller is based on system configuration registers which are mapped
via regmap. This reset controller does not have any feedback or
acknowledgement. With this patch a new device "st,stih415-softreset" is
registered with system configuration registers based reset controller
that controls the softreset state of the hardware such as Ethernet, IRB.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla-qxv4g6HH51o@public.gmane.org>
---
.../devicetree/bindings/reset/st,sti-softreset.txt | 46 ++++++++++++++++++++
arch/arm/boot/dts/stih415.dtsi | 5 +++
drivers/reset/sti/reset-stih415.c | 35 +++++++++++++++
.../dt-bindings/reset-controller/stih415-resets.h | 7 +++
4 files changed, 93 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reset/st,sti-softreset.txt
diff --git a/Documentation/devicetree/bindings/reset/st,sti-softreset.txt b/Documentation/devicetree/bindings/reset/st,sti-softreset.txt
new file mode 100644
index 0000000..a8d3d3c
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/st,sti-softreset.txt
@@ -0,0 +1,46 @@
+STMicroelectronics STi family Sysconfig Peripheral SoftReset Controller
+=============================================================================
+
+This binding describes a reset controller device that is used to enable and
+disable on-chip peripheral controllers such as USB and SATA, using
+"softreset" control bits found in the STi family SoC system configuration
+registers.
+
+The actual action taken when softreset is asserted is hardware dependent.
+However, when asserted it may not be possible to access the hardware's
+registers and after an assert/deassert sequence the hardware's previous state
+may no longer be valid.
+
+Please refer to reset.txt in this directory for common reset
+controller binding usage.
+
+Required properties:
+- compatible: Should be "st,<chip>-softreset" example:
+ "st,stih415-softreset" or "st,stih416-softreset";
+- #reset-cells: 1, see below
+
+example:
+
+ softreset: softreset-controller {
+ #reset-cells = <1>;
+ compatible = "st,stih415-softreset";
+ };
+
+
+Specifying softreset control of devices
+=======================================
+
+Device nodes should specify the reset channel required in their "resets"
+property, containing a phandle to the softreset device node and an
+index specifying which channel to use, as described in reset.txt
+
+example:
+
+ ethernet0{
+ resets = <&softreset STIH415_ETH0_SOFTRESET>;
+ };
+
+Macro definitions for the supported reset channels can be found in:
+
+include/dt-bindings/reset-controller/stih415-resets.h
+include/dt-bindings/reset-controller/stih416-resets.h
diff --git a/arch/arm/boot/dts/stih415.dtsi b/arch/arm/boot/dts/stih415.dtsi
index 19e29f4..d52207c 100644
--- a/arch/arm/boot/dts/stih415.dtsi
+++ b/arch/arm/boot/dts/stih415.dtsi
@@ -34,6 +34,11 @@
compatible = "st,stih415-powerdown";
};
+ softreset: softreset-controller {
+ #reset-cells = <1>;
+ compatible = "st,stih415-softreset";
+ };
+
syscfg_sbc: sbc-syscfg@fe600000{
compatible = "st,stih415-sbc-syscfg", "syscon";
reg = <0xfe600000 0xb4>;
diff --git a/drivers/reset/sti/reset-stih415.c b/drivers/reset/sti/reset-stih415.c
index 56c2146..e6f6c41 100644
--- a/drivers/reset/sti/reset-stih415.c
+++ b/drivers/reset/sti/reset-stih415.c
@@ -31,12 +31,29 @@ static const char stih415_lpm[] = "st,stih415-lpm-syscfg";
#define STIH415_PDN_REAR(_cntl, _stat) \
_SYSCFG_RST_CH(stih415_rear, SYSCFG_336, _cntl, SYSSTAT_384, _stat)
+#define STIH415_SRST_REAR(_reg, _bit) \
+ _SYSCFG_RST_CH_NO_ACK(stih415_rear, _reg, _bit)
+
+#define STIH415_SRST_SBC(_reg, _bit) \
+ _SYSCFG_RST_CH_NO_ACK(stih415_sbc, _reg, _bit)
+
+#define STIH415_SRST_FRONT(_reg, _bit) \
+ _SYSCFG_RST_CH_NO_ACK(stih415_front, _reg, _bit)
+
+#define STIH415_SRST_LPM(_reg, _bit) \
+ _SYSCFG_RST_CH_NO_ACK(stih415_lpm, _reg, _bit)
+
#define SYSCFG_114 0x38 /* Powerdown request EMI/NAND/Keyscan */
#define SYSSTAT_187 0x15c /* Powerdown status EMI/NAND/Keyscan */
#define SYSCFG_336 0x90 /* Powerdown request USB/SATA/PCIe */
#define SYSSTAT_384 0x150 /* Powerdown status USB/SATA/PCIe */
+#define SYSCFG_376 0x130 /* Reset generator 0 control 0 */
+#define SYSCFG_166 0x108 /* Softreset Ethernet 0 */
+#define SYSCFG_31 0x7c /* Softreset Ethernet 1 */
+#define LPM_SYSCFG_1 0x4 /* Softreset IRB */
+
static const struct syscfg_reset_channel_data stih415_powerdowns[] = {
[STIH415_EMISS_POWERDOWN] = STIH415_PDN_FRONT(0),
[STIH415_NAND_POWERDOWN] = STIH415_PDN_FRONT(1),
@@ -49,15 +66,33 @@ static const struct syscfg_reset_channel_data stih415_powerdowns[] = {
[STIH415_PCIE_POWERDOWN] = STIH415_PDN_REAR(5, 8),
};
+static const struct syscfg_reset_channel_data stih415_softresets[] = {
+ [STIH415_ETH0_SOFTRESET] = STIH415_SRST_FRONT(SYSCFG_166, 0),
+ [STIH415_ETH1_SOFTRESET] = STIH415_SRST_SBC(SYSCFG_31, 0),
+ [STIH415_IRB_SOFTRESET] = STIH415_SRST_LPM(LPM_SYSCFG_1, 6),
+ [STIH415_USB0_SOFTRESET] = STIH415_SRST_REAR(SYSCFG_376, 9),
+ [STIH415_USB1_SOFTRESET] = STIH415_SRST_REAR(SYSCFG_376, 10),
+ [STIH415_USB2_SOFTRESET] = STIH415_SRST_REAR(SYSCFG_376, 11),
+};
+
static struct syscfg_reset_controller_data stih415_powerdown_controller = {
.wait_for_ack = true,
.nr_channels = ARRAY_SIZE(stih415_powerdowns),
.channels = stih415_powerdowns,
};
+static struct syscfg_reset_controller_data stih415_softreset_controller = {
+ .wait_for_ack = false,
+ .active_low = true,
+ .nr_channels = ARRAY_SIZE(stih415_softresets),
+ .channels = stih415_softresets,
+};
+
static struct of_device_id stih415_reset_match[] = {
{ .compatible = "st,stih415-powerdown",
.data = &stih415_powerdown_controller, },
+ { .compatible = "st,stih415-softreset",
+ .data = &stih415_softreset_controller, },
{},
};
diff --git a/include/dt-bindings/reset-controller/stih415-resets.h b/include/dt-bindings/reset-controller/stih415-resets.h
index 2d54e68..c2f8a66 100644
--- a/include/dt-bindings/reset-controller/stih415-resets.h
+++ b/include/dt-bindings/reset-controller/stih415-resets.h
@@ -16,4 +16,11 @@
#define STIH415_SATA1_POWERDOWN 7
#define STIH415_PCIE_POWERDOWN 8
+#define STIH415_ETH0_SOFTRESET 0
+#define STIH415_ETH1_SOFTRESET 1
+#define STIH415_IRB_SOFTRESET 2
+#define STIH415_USB0_SOFTRESET 3
+#define STIH415_USB1_SOFTRESET 4
+#define STIH415_USB2_SOFTRESET 5
+
#endif /* _DT_BINDINGS_RESET_CONTROLLER_STIH415 */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 72+ messages in thread
* [PATCH v2 5/6] drivers: reset: stih416: add softreset controller
2014-02-03 14:27 ` srinivas.kandagatla
(?)
@ 2014-02-03 14:28 ` srinivas.kandagatla
-1 siblings, 0 replies; 72+ messages in thread
From: srinivas.kandagatla @ 2014-02-03 14:28 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Philipp Zabel, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Rob Landley, Russell King,
Srinivas Kandagatla, Stuart Menefy, Grant Likely, devicetree,
linux-doc, linux-kernel, kernel, Arnd Bergmann,
stephen.gallimore, Olof Johansson
From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
This patch adds softreset controller for STiH416 SOC, soft reset
controller is based on system configuration registers which are mapped
via regmap. This reset controller does not have any feedback or
acknowledgement. With this patch a new device "st,stih416-softreset" is
registered with system configuration registers based reset controller
that controls the softreset state of the hardware such as Ethernet, IRB.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
---
arch/arm/boot/dts/stih416.dtsi | 5 ++
drivers/reset/sti/reset-stih416.c | 64 ++++++++++++++++++++
.../dt-bindings/reset-controller/stih416-resets.h | 29 +++++++++
3 files changed, 98 insertions(+)
diff --git a/arch/arm/boot/dts/stih416.dtsi b/arch/arm/boot/dts/stih416.dtsi
index e5bec66..788ba5b 100644
--- a/arch/arm/boot/dts/stih416.dtsi
+++ b/arch/arm/boot/dts/stih416.dtsi
@@ -33,6 +33,11 @@
compatible = "st,stih416-powerdown";
};
+ softreset: softreset-controller {
+ #reset-cells = <1>;
+ compatible = "st,stih416-softreset";
+ };
+
syscfg_sbc:sbc-syscfg@fe600000{
compatible = "st,stih416-sbc-syscfg", "syscon";
reg = <0xfe600000 0x1000>;
diff --git a/drivers/reset/sti/reset-stih416.c b/drivers/reset/sti/reset-stih416.c
index 0becfc5..fe3bf02 100644
--- a/drivers/reset/sti/reset-stih416.c
+++ b/drivers/reset/sti/reset-stih416.c
@@ -24,6 +24,7 @@ static const char stih416_front[] = "st,stih416-front-syscfg";
static const char stih416_rear[] = "st,stih416-rear-syscfg";
static const char stih416_sbc[] = "st,stih416-sbc-syscfg";
static const char stih416_lpm[] = "st,stih416-lpm-syscfg";
+static const char stih416_cpu[] = "st,stih416-cpu-syscfg";
#define STIH416_PDN_FRONT(_bit) \
_SYSCFG_RST_CH(stih416_front, SYSCFG_1500, _bit, SYSSTAT_1578, _bit)
@@ -37,6 +38,29 @@ static const char stih416_lpm[] = "st,stih416-lpm-syscfg";
#define SYSCFG_2525 0x834 /* Powerdown request USB/SATA/PCIe */
#define SYSSTAT_2583 0x91c /* Powerdown status USB/SATA/PCIe */
+#define SYSCFG_2552 0x8A0 /* Reset Generator control 0 */
+#define SYSCFG_1539 0x86c /* Softreset Ethernet 0 */
+#define SYSCFG_510 0x7f8 /* Softreset Ethernet 1 */
+#define LPM_SYSCFG_1 0x4 /* Softreset IRB */
+#define SYSCFG_2553 0x8a4 /* Softreset SATA0/1, PCIE0/1 */
+#define SYSCFG_7563 0x8cc /* MPE softresets 0 */
+#define SYSCFG_7564 0x8d0 /* MPE softresets 1 */
+
+#define STIH416_SRST_CPU(_reg, _bit) \
+ _SYSCFG_RST_CH_NO_ACK(stih416_cpu, _reg, _bit)
+
+#define STIH416_SRST_FRONT(_reg, _bit) \
+ _SYSCFG_RST_CH_NO_ACK(stih416_front, _reg, _bit)
+
+#define STIH416_SRST_REAR(_reg, _bit) \
+ _SYSCFG_RST_CH_NO_ACK(stih416_rear, _reg, _bit)
+
+#define STIH416_SRST_LPM(_reg, _bit) \
+ _SYSCFG_RST_CH_NO_ACK(stih416_lpm, _reg, _bit)
+
+#define STIH416_SRST_SBC(_reg, _bit) \
+ _SYSCFG_RST_CH_NO_ACK(stih416_sbc, _reg, _bit)
+
static const struct syscfg_reset_channel_data stih416_powerdowns[] = {
[STIH416_EMISS_POWERDOWN] = STIH416_PDN_FRONT(0),
[STIH416_NAND_POWERDOWN] = STIH416_PDN_FRONT(1),
@@ -51,15 +75,55 @@ static const struct syscfg_reset_channel_data stih416_powerdowns[] = {
[STIH416_PCIE1_POWERDOWN] = STIH416_PDN_REAR(5, 8),
};
+static const struct syscfg_reset_channel_data stih416_softresets[] = {
+ [STIH416_ETH0_SOFTRESET] = STIH416_SRST_FRONT(SYSCFG_1539, 0),
+ [STIH416_ETH1_SOFTRESET] = STIH416_SRST_SBC(SYSCFG_510, 0),
+ [STIH416_IRB_SOFTRESET] = STIH416_SRST_LPM(LPM_SYSCFG_1, 6),
+ [STIH416_USB0_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2552, 9),
+ [STIH416_USB1_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2552, 10),
+ [STIH416_USB2_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2552, 11),
+ [STIH416_USB3_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2552, 28),
+ [STIH416_SATA0_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2553, 7),
+ [STIH416_SATA1_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2553, 3),
+ [STIH416_PCIE0_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2553, 15),
+ [STIH416_PCIE1_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2553, 2),
+ [STIH416_AUD_DAC_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2553, 14),
+ [STIH416_HDTVOUT_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2552, 5),
+ [STIH416_VTAC_M_RX_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2552, 25),
+ [STIH416_VTAC_A_RX_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2552, 26),
+ [STIH416_SYNC_HD_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2553, 5),
+ [STIH416_SYNC_SD_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2553, 6),
+ [STIH416_BLITTER_SOFTRESET] = STIH416_SRST_CPU(SYSCFG_7563, 10),
+ [STIH416_GPU_SOFTRESET] = STIH416_SRST_CPU(SYSCFG_7563, 11),
+ [STIH416_VTAC_M_TX_SOFTRESET] = STIH416_SRST_CPU(SYSCFG_7563, 18),
+ [STIH416_VTAC_A_TX_SOFTRESET] = STIH416_SRST_CPU(SYSCFG_7563, 19),
+ [STIH416_VTG_AUX_SOFTRESET] = STIH416_SRST_CPU(SYSCFG_7563, 21),
+ [STIH416_JPEG_DEC_SOFTRESET] = STIH416_SRST_CPU(SYSCFG_7563, 23),
+ [STIH416_HVA_SOFTRESET] = STIH416_SRST_CPU(SYSCFG_7564, 2),
+ [STIH416_COMPO_M_SOFTRESET] = STIH416_SRST_CPU(SYSCFG_7564, 3),
+ [STIH416_COMPO_A_SOFTRESET] = STIH416_SRST_CPU(SYSCFG_7564, 4),
+ [STIH416_VP8_DEC_SOFTRESET] = STIH416_SRST_CPU(SYSCFG_7564, 10),
+ [STIH416_VTG_MAIN_SOFTRESET] = STIH416_SRST_CPU(SYSCFG_7564, 16),
+};
+
static struct syscfg_reset_controller_data stih416_powerdown_controller = {
.wait_for_ack = true,
.nr_channels = ARRAY_SIZE(stih416_powerdowns),
.channels = stih416_powerdowns,
};
+static struct syscfg_reset_controller_data stih416_softreset_controller = {
+ .wait_for_ack = false,
+ .active_low = true,
+ .nr_channels = ARRAY_SIZE(stih416_softresets),
+ .channels = stih416_softresets,
+};
+
static struct of_device_id stih416_reset_match[] = {
{ .compatible = "st,stih416-powerdown",
.data = &stih416_powerdown_controller, },
+ { .compatible = "st,stih416-softreset",
+ .data = &stih416_softreset_controller, },
{},
};
diff --git a/include/dt-bindings/reset-controller/stih416-resets.h b/include/dt-bindings/reset-controller/stih416-resets.h
index d7da55f..2127743 100644
--- a/include/dt-bindings/reset-controller/stih416-resets.h
+++ b/include/dt-bindings/reset-controller/stih416-resets.h
@@ -18,4 +18,33 @@
#define STIH416_PCIE0_POWERDOWN 9
#define STIH416_PCIE1_POWERDOWN 10
+#define STIH416_ETH0_SOFTRESET 0
+#define STIH416_ETH1_SOFTRESET 1
+#define STIH416_IRB_SOFTRESET 2
+#define STIH416_USB0_SOFTRESET 3
+#define STIH416_USB1_SOFTRESET 4
+#define STIH416_USB2_SOFTRESET 5
+#define STIH416_USB3_SOFTRESET 6
+#define STIH416_SATA0_SOFTRESET 7
+#define STIH416_SATA1_SOFTRESET 8
+#define STIH416_PCIE0_SOFTRESET 9
+#define STIH416_PCIE1_SOFTRESET 10
+#define STIH416_AUD_DAC_SOFTRESET 11
+#define STIH416_HDTVOUT_SOFTRESET 12
+#define STIH416_VTAC_M_RX_SOFTRESET 13
+#define STIH416_VTAC_A_RX_SOFTRESET 14
+#define STIH416_SYNC_HD_SOFTRESET 15
+#define STIH416_SYNC_SD_SOFTRESET 16
+#define STIH416_BLITTER_SOFTRESET 17
+#define STIH416_GPU_SOFTRESET 18
+#define STIH416_VTAC_M_TX_SOFTRESET 19
+#define STIH416_VTAC_A_TX_SOFTRESET 20
+#define STIH416_VTG_AUX_SOFTRESET 21
+#define STIH416_JPEG_DEC_SOFTRESET 22
+#define STIH416_HVA_SOFTRESET 23
+#define STIH416_COMPO_M_SOFTRESET 24
+#define STIH416_COMPO_A_SOFTRESET 25
+#define STIH416_VP8_DEC_SOFTRESET 26
+#define STIH416_VTG_MAIN_SOFTRESET 27
+
#endif /* _DT_BINDINGS_RESET_CONTROLLER_STIH416 */
--
1.7.9.5
^ permalink raw reply related [flat|nested] 72+ messages in thread* [PATCH v2 5/6] drivers: reset: stih416: add softreset controller
@ 2014-02-03 14:28 ` srinivas.kandagatla
0 siblings, 0 replies; 72+ messages in thread
From: srinivas.kandagatla at st.com @ 2014-02-03 14:28 UTC (permalink / raw)
To: linux-arm-kernel
From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
This patch adds softreset controller for STiH416 SOC, soft reset
controller is based on system configuration registers which are mapped
via regmap. This reset controller does not have any feedback or
acknowledgement. With this patch a new device "st,stih416-softreset" is
registered with system configuration registers based reset controller
that controls the softreset state of the hardware such as Ethernet, IRB.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
---
arch/arm/boot/dts/stih416.dtsi | 5 ++
drivers/reset/sti/reset-stih416.c | 64 ++++++++++++++++++++
.../dt-bindings/reset-controller/stih416-resets.h | 29 +++++++++
3 files changed, 98 insertions(+)
diff --git a/arch/arm/boot/dts/stih416.dtsi b/arch/arm/boot/dts/stih416.dtsi
index e5bec66..788ba5b 100644
--- a/arch/arm/boot/dts/stih416.dtsi
+++ b/arch/arm/boot/dts/stih416.dtsi
@@ -33,6 +33,11 @@
compatible = "st,stih416-powerdown";
};
+ softreset: softreset-controller {
+ #reset-cells = <1>;
+ compatible = "st,stih416-softreset";
+ };
+
syscfg_sbc:sbc-syscfg at fe600000{
compatible = "st,stih416-sbc-syscfg", "syscon";
reg = <0xfe600000 0x1000>;
diff --git a/drivers/reset/sti/reset-stih416.c b/drivers/reset/sti/reset-stih416.c
index 0becfc5..fe3bf02 100644
--- a/drivers/reset/sti/reset-stih416.c
+++ b/drivers/reset/sti/reset-stih416.c
@@ -24,6 +24,7 @@ static const char stih416_front[] = "st,stih416-front-syscfg";
static const char stih416_rear[] = "st,stih416-rear-syscfg";
static const char stih416_sbc[] = "st,stih416-sbc-syscfg";
static const char stih416_lpm[] = "st,stih416-lpm-syscfg";
+static const char stih416_cpu[] = "st,stih416-cpu-syscfg";
#define STIH416_PDN_FRONT(_bit) \
_SYSCFG_RST_CH(stih416_front, SYSCFG_1500, _bit, SYSSTAT_1578, _bit)
@@ -37,6 +38,29 @@ static const char stih416_lpm[] = "st,stih416-lpm-syscfg";
#define SYSCFG_2525 0x834 /* Powerdown request USB/SATA/PCIe */
#define SYSSTAT_2583 0x91c /* Powerdown status USB/SATA/PCIe */
+#define SYSCFG_2552 0x8A0 /* Reset Generator control 0 */
+#define SYSCFG_1539 0x86c /* Softreset Ethernet 0 */
+#define SYSCFG_510 0x7f8 /* Softreset Ethernet 1 */
+#define LPM_SYSCFG_1 0x4 /* Softreset IRB */
+#define SYSCFG_2553 0x8a4 /* Softreset SATA0/1, PCIE0/1 */
+#define SYSCFG_7563 0x8cc /* MPE softresets 0 */
+#define SYSCFG_7564 0x8d0 /* MPE softresets 1 */
+
+#define STIH416_SRST_CPU(_reg, _bit) \
+ _SYSCFG_RST_CH_NO_ACK(stih416_cpu, _reg, _bit)
+
+#define STIH416_SRST_FRONT(_reg, _bit) \
+ _SYSCFG_RST_CH_NO_ACK(stih416_front, _reg, _bit)
+
+#define STIH416_SRST_REAR(_reg, _bit) \
+ _SYSCFG_RST_CH_NO_ACK(stih416_rear, _reg, _bit)
+
+#define STIH416_SRST_LPM(_reg, _bit) \
+ _SYSCFG_RST_CH_NO_ACK(stih416_lpm, _reg, _bit)
+
+#define STIH416_SRST_SBC(_reg, _bit) \
+ _SYSCFG_RST_CH_NO_ACK(stih416_sbc, _reg, _bit)
+
static const struct syscfg_reset_channel_data stih416_powerdowns[] = {
[STIH416_EMISS_POWERDOWN] = STIH416_PDN_FRONT(0),
[STIH416_NAND_POWERDOWN] = STIH416_PDN_FRONT(1),
@@ -51,15 +75,55 @@ static const struct syscfg_reset_channel_data stih416_powerdowns[] = {
[STIH416_PCIE1_POWERDOWN] = STIH416_PDN_REAR(5, 8),
};
+static const struct syscfg_reset_channel_data stih416_softresets[] = {
+ [STIH416_ETH0_SOFTRESET] = STIH416_SRST_FRONT(SYSCFG_1539, 0),
+ [STIH416_ETH1_SOFTRESET] = STIH416_SRST_SBC(SYSCFG_510, 0),
+ [STIH416_IRB_SOFTRESET] = STIH416_SRST_LPM(LPM_SYSCFG_1, 6),
+ [STIH416_USB0_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2552, 9),
+ [STIH416_USB1_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2552, 10),
+ [STIH416_USB2_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2552, 11),
+ [STIH416_USB3_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2552, 28),
+ [STIH416_SATA0_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2553, 7),
+ [STIH416_SATA1_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2553, 3),
+ [STIH416_PCIE0_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2553, 15),
+ [STIH416_PCIE1_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2553, 2),
+ [STIH416_AUD_DAC_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2553, 14),
+ [STIH416_HDTVOUT_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2552, 5),
+ [STIH416_VTAC_M_RX_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2552, 25),
+ [STIH416_VTAC_A_RX_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2552, 26),
+ [STIH416_SYNC_HD_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2553, 5),
+ [STIH416_SYNC_SD_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2553, 6),
+ [STIH416_BLITTER_SOFTRESET] = STIH416_SRST_CPU(SYSCFG_7563, 10),
+ [STIH416_GPU_SOFTRESET] = STIH416_SRST_CPU(SYSCFG_7563, 11),
+ [STIH416_VTAC_M_TX_SOFTRESET] = STIH416_SRST_CPU(SYSCFG_7563, 18),
+ [STIH416_VTAC_A_TX_SOFTRESET] = STIH416_SRST_CPU(SYSCFG_7563, 19),
+ [STIH416_VTG_AUX_SOFTRESET] = STIH416_SRST_CPU(SYSCFG_7563, 21),
+ [STIH416_JPEG_DEC_SOFTRESET] = STIH416_SRST_CPU(SYSCFG_7563, 23),
+ [STIH416_HVA_SOFTRESET] = STIH416_SRST_CPU(SYSCFG_7564, 2),
+ [STIH416_COMPO_M_SOFTRESET] = STIH416_SRST_CPU(SYSCFG_7564, 3),
+ [STIH416_COMPO_A_SOFTRESET] = STIH416_SRST_CPU(SYSCFG_7564, 4),
+ [STIH416_VP8_DEC_SOFTRESET] = STIH416_SRST_CPU(SYSCFG_7564, 10),
+ [STIH416_VTG_MAIN_SOFTRESET] = STIH416_SRST_CPU(SYSCFG_7564, 16),
+};
+
static struct syscfg_reset_controller_data stih416_powerdown_controller = {
.wait_for_ack = true,
.nr_channels = ARRAY_SIZE(stih416_powerdowns),
.channels = stih416_powerdowns,
};
+static struct syscfg_reset_controller_data stih416_softreset_controller = {
+ .wait_for_ack = false,
+ .active_low = true,
+ .nr_channels = ARRAY_SIZE(stih416_softresets),
+ .channels = stih416_softresets,
+};
+
static struct of_device_id stih416_reset_match[] = {
{ .compatible = "st,stih416-powerdown",
.data = &stih416_powerdown_controller, },
+ { .compatible = "st,stih416-softreset",
+ .data = &stih416_softreset_controller, },
{},
};
diff --git a/include/dt-bindings/reset-controller/stih416-resets.h b/include/dt-bindings/reset-controller/stih416-resets.h
index d7da55f..2127743 100644
--- a/include/dt-bindings/reset-controller/stih416-resets.h
+++ b/include/dt-bindings/reset-controller/stih416-resets.h
@@ -18,4 +18,33 @@
#define STIH416_PCIE0_POWERDOWN 9
#define STIH416_PCIE1_POWERDOWN 10
+#define STIH416_ETH0_SOFTRESET 0
+#define STIH416_ETH1_SOFTRESET 1
+#define STIH416_IRB_SOFTRESET 2
+#define STIH416_USB0_SOFTRESET 3
+#define STIH416_USB1_SOFTRESET 4
+#define STIH416_USB2_SOFTRESET 5
+#define STIH416_USB3_SOFTRESET 6
+#define STIH416_SATA0_SOFTRESET 7
+#define STIH416_SATA1_SOFTRESET 8
+#define STIH416_PCIE0_SOFTRESET 9
+#define STIH416_PCIE1_SOFTRESET 10
+#define STIH416_AUD_DAC_SOFTRESET 11
+#define STIH416_HDTVOUT_SOFTRESET 12
+#define STIH416_VTAC_M_RX_SOFTRESET 13
+#define STIH416_VTAC_A_RX_SOFTRESET 14
+#define STIH416_SYNC_HD_SOFTRESET 15
+#define STIH416_SYNC_SD_SOFTRESET 16
+#define STIH416_BLITTER_SOFTRESET 17
+#define STIH416_GPU_SOFTRESET 18
+#define STIH416_VTAC_M_TX_SOFTRESET 19
+#define STIH416_VTAC_A_TX_SOFTRESET 20
+#define STIH416_VTG_AUX_SOFTRESET 21
+#define STIH416_JPEG_DEC_SOFTRESET 22
+#define STIH416_HVA_SOFTRESET 23
+#define STIH416_COMPO_M_SOFTRESET 24
+#define STIH416_COMPO_A_SOFTRESET 25
+#define STIH416_VP8_DEC_SOFTRESET 26
+#define STIH416_VTG_MAIN_SOFTRESET 27
+
#endif /* _DT_BINDINGS_RESET_CONTROLLER_STIH416 */
--
1.7.9.5
^ permalink raw reply related [flat|nested] 72+ messages in thread* [PATCH v2 5/6] drivers: reset: stih416: add softreset controller
@ 2014-02-03 14:28 ` srinivas.kandagatla
0 siblings, 0 replies; 72+ messages in thread
From: srinivas.kandagatla @ 2014-02-03 14:28 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Philipp Zabel, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Rob Landley, Russell King,
Srinivas Kandagatla, Stuart Menefy, Grant Likely, devicetree,
linux-doc, linux-kernel, kernel, Arnd Bergmann,
stephen.gallimore, Olof Johansson
From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
This patch adds softreset controller for STiH416 SOC, soft reset
controller is based on system configuration registers which are mapped
via regmap. This reset controller does not have any feedback or
acknowledgement. With this patch a new device "st,stih416-softreset" is
registered with system configuration registers based reset controller
that controls the softreset state of the hardware such as Ethernet, IRB.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
---
arch/arm/boot/dts/stih416.dtsi | 5 ++
drivers/reset/sti/reset-stih416.c | 64 ++++++++++++++++++++
.../dt-bindings/reset-controller/stih416-resets.h | 29 +++++++++
3 files changed, 98 insertions(+)
diff --git a/arch/arm/boot/dts/stih416.dtsi b/arch/arm/boot/dts/stih416.dtsi
index e5bec66..788ba5b 100644
--- a/arch/arm/boot/dts/stih416.dtsi
+++ b/arch/arm/boot/dts/stih416.dtsi
@@ -33,6 +33,11 @@
compatible = "st,stih416-powerdown";
};
+ softreset: softreset-controller {
+ #reset-cells = <1>;
+ compatible = "st,stih416-softreset";
+ };
+
syscfg_sbc:sbc-syscfg@fe600000{
compatible = "st,stih416-sbc-syscfg", "syscon";
reg = <0xfe600000 0x1000>;
diff --git a/drivers/reset/sti/reset-stih416.c b/drivers/reset/sti/reset-stih416.c
index 0becfc5..fe3bf02 100644
--- a/drivers/reset/sti/reset-stih416.c
+++ b/drivers/reset/sti/reset-stih416.c
@@ -24,6 +24,7 @@ static const char stih416_front[] = "st,stih416-front-syscfg";
static const char stih416_rear[] = "st,stih416-rear-syscfg";
static const char stih416_sbc[] = "st,stih416-sbc-syscfg";
static const char stih416_lpm[] = "st,stih416-lpm-syscfg";
+static const char stih416_cpu[] = "st,stih416-cpu-syscfg";
#define STIH416_PDN_FRONT(_bit) \
_SYSCFG_RST_CH(stih416_front, SYSCFG_1500, _bit, SYSSTAT_1578, _bit)
@@ -37,6 +38,29 @@ static const char stih416_lpm[] = "st,stih416-lpm-syscfg";
#define SYSCFG_2525 0x834 /* Powerdown request USB/SATA/PCIe */
#define SYSSTAT_2583 0x91c /* Powerdown status USB/SATA/PCIe */
+#define SYSCFG_2552 0x8A0 /* Reset Generator control 0 */
+#define SYSCFG_1539 0x86c /* Softreset Ethernet 0 */
+#define SYSCFG_510 0x7f8 /* Softreset Ethernet 1 */
+#define LPM_SYSCFG_1 0x4 /* Softreset IRB */
+#define SYSCFG_2553 0x8a4 /* Softreset SATA0/1, PCIE0/1 */
+#define SYSCFG_7563 0x8cc /* MPE softresets 0 */
+#define SYSCFG_7564 0x8d0 /* MPE softresets 1 */
+
+#define STIH416_SRST_CPU(_reg, _bit) \
+ _SYSCFG_RST_CH_NO_ACK(stih416_cpu, _reg, _bit)
+
+#define STIH416_SRST_FRONT(_reg, _bit) \
+ _SYSCFG_RST_CH_NO_ACK(stih416_front, _reg, _bit)
+
+#define STIH416_SRST_REAR(_reg, _bit) \
+ _SYSCFG_RST_CH_NO_ACK(stih416_rear, _reg, _bit)
+
+#define STIH416_SRST_LPM(_reg, _bit) \
+ _SYSCFG_RST_CH_NO_ACK(stih416_lpm, _reg, _bit)
+
+#define STIH416_SRST_SBC(_reg, _bit) \
+ _SYSCFG_RST_CH_NO_ACK(stih416_sbc, _reg, _bit)
+
static const struct syscfg_reset_channel_data stih416_powerdowns[] = {
[STIH416_EMISS_POWERDOWN] = STIH416_PDN_FRONT(0),
[STIH416_NAND_POWERDOWN] = STIH416_PDN_FRONT(1),
@@ -51,15 +75,55 @@ static const struct syscfg_reset_channel_data stih416_powerdowns[] = {
[STIH416_PCIE1_POWERDOWN] = STIH416_PDN_REAR(5, 8),
};
+static const struct syscfg_reset_channel_data stih416_softresets[] = {
+ [STIH416_ETH0_SOFTRESET] = STIH416_SRST_FRONT(SYSCFG_1539, 0),
+ [STIH416_ETH1_SOFTRESET] = STIH416_SRST_SBC(SYSCFG_510, 0),
+ [STIH416_IRB_SOFTRESET] = STIH416_SRST_LPM(LPM_SYSCFG_1, 6),
+ [STIH416_USB0_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2552, 9),
+ [STIH416_USB1_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2552, 10),
+ [STIH416_USB2_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2552, 11),
+ [STIH416_USB3_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2552, 28),
+ [STIH416_SATA0_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2553, 7),
+ [STIH416_SATA1_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2553, 3),
+ [STIH416_PCIE0_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2553, 15),
+ [STIH416_PCIE1_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2553, 2),
+ [STIH416_AUD_DAC_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2553, 14),
+ [STIH416_HDTVOUT_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2552, 5),
+ [STIH416_VTAC_M_RX_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2552, 25),
+ [STIH416_VTAC_A_RX_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2552, 26),
+ [STIH416_SYNC_HD_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2553, 5),
+ [STIH416_SYNC_SD_SOFTRESET] = STIH416_SRST_REAR(SYSCFG_2553, 6),
+ [STIH416_BLITTER_SOFTRESET] = STIH416_SRST_CPU(SYSCFG_7563, 10),
+ [STIH416_GPU_SOFTRESET] = STIH416_SRST_CPU(SYSCFG_7563, 11),
+ [STIH416_VTAC_M_TX_SOFTRESET] = STIH416_SRST_CPU(SYSCFG_7563, 18),
+ [STIH416_VTAC_A_TX_SOFTRESET] = STIH416_SRST_CPU(SYSCFG_7563, 19),
+ [STIH416_VTG_AUX_SOFTRESET] = STIH416_SRST_CPU(SYSCFG_7563, 21),
+ [STIH416_JPEG_DEC_SOFTRESET] = STIH416_SRST_CPU(SYSCFG_7563, 23),
+ [STIH416_HVA_SOFTRESET] = STIH416_SRST_CPU(SYSCFG_7564, 2),
+ [STIH416_COMPO_M_SOFTRESET] = STIH416_SRST_CPU(SYSCFG_7564, 3),
+ [STIH416_COMPO_A_SOFTRESET] = STIH416_SRST_CPU(SYSCFG_7564, 4),
+ [STIH416_VP8_DEC_SOFTRESET] = STIH416_SRST_CPU(SYSCFG_7564, 10),
+ [STIH416_VTG_MAIN_SOFTRESET] = STIH416_SRST_CPU(SYSCFG_7564, 16),
+};
+
static struct syscfg_reset_controller_data stih416_powerdown_controller = {
.wait_for_ack = true,
.nr_channels = ARRAY_SIZE(stih416_powerdowns),
.channels = stih416_powerdowns,
};
+static struct syscfg_reset_controller_data stih416_softreset_controller = {
+ .wait_for_ack = false,
+ .active_low = true,
+ .nr_channels = ARRAY_SIZE(stih416_softresets),
+ .channels = stih416_softresets,
+};
+
static struct of_device_id stih416_reset_match[] = {
{ .compatible = "st,stih416-powerdown",
.data = &stih416_powerdown_controller, },
+ { .compatible = "st,stih416-softreset",
+ .data = &stih416_softreset_controller, },
{},
};
diff --git a/include/dt-bindings/reset-controller/stih416-resets.h b/include/dt-bindings/reset-controller/stih416-resets.h
index d7da55f..2127743 100644
--- a/include/dt-bindings/reset-controller/stih416-resets.h
+++ b/include/dt-bindings/reset-controller/stih416-resets.h
@@ -18,4 +18,33 @@
#define STIH416_PCIE0_POWERDOWN 9
#define STIH416_PCIE1_POWERDOWN 10
+#define STIH416_ETH0_SOFTRESET 0
+#define STIH416_ETH1_SOFTRESET 1
+#define STIH416_IRB_SOFTRESET 2
+#define STIH416_USB0_SOFTRESET 3
+#define STIH416_USB1_SOFTRESET 4
+#define STIH416_USB2_SOFTRESET 5
+#define STIH416_USB3_SOFTRESET 6
+#define STIH416_SATA0_SOFTRESET 7
+#define STIH416_SATA1_SOFTRESET 8
+#define STIH416_PCIE0_SOFTRESET 9
+#define STIH416_PCIE1_SOFTRESET 10
+#define STIH416_AUD_DAC_SOFTRESET 11
+#define STIH416_HDTVOUT_SOFTRESET 12
+#define STIH416_VTAC_M_RX_SOFTRESET 13
+#define STIH416_VTAC_A_RX_SOFTRESET 14
+#define STIH416_SYNC_HD_SOFTRESET 15
+#define STIH416_SYNC_SD_SOFTRESET 16
+#define STIH416_BLITTER_SOFTRESET 17
+#define STIH416_GPU_SOFTRESET 18
+#define STIH416_VTAC_M_TX_SOFTRESET 19
+#define STIH416_VTAC_A_TX_SOFTRESET 20
+#define STIH416_VTG_AUX_SOFTRESET 21
+#define STIH416_JPEG_DEC_SOFTRESET 22
+#define STIH416_HVA_SOFTRESET 23
+#define STIH416_COMPO_M_SOFTRESET 24
+#define STIH416_COMPO_A_SOFTRESET 25
+#define STIH416_VP8_DEC_SOFTRESET 26
+#define STIH416_VTG_MAIN_SOFTRESET 27
+
#endif /* _DT_BINDINGS_RESET_CONTROLLER_STIH416 */
--
1.7.9.5
^ permalink raw reply related [flat|nested] 72+ messages in thread
* [PATCH v2 6/6] ARM: STi: Add reset controller support to mach-sti Kconfig
2014-02-03 14:27 ` srinivas.kandagatla
(?)
@ 2014-02-03 14:29 ` srinivas.kandagatla
-1 siblings, 0 replies; 72+ messages in thread
From: srinivas.kandagatla @ 2014-02-03 14:29 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Philipp Zabel, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Rob Landley, Russell King,
Srinivas Kandagatla, Stuart Menefy, Grant Likely, devicetree,
linux-doc, linux-kernel, kernel, Arnd Bergmann,
stephen.gallimore, Olof Johansson
From: Stephen Gallimore <stephen.gallimore@st.com>
This patch selects reset controller support for ARCH_STI and
selects the reset controllers for STiH415 and STiH416 SoCs.
Signed-off-by: Stephen Gallimore <stephen.gallimore@st.com>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
---
arch/arm/mach-sti/Kconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-sti/Kconfig b/arch/arm/mach-sti/Kconfig
index d71654b..2550620 100644
--- a/arch/arm/mach-sti/Kconfig
+++ b/arch/arm/mach-sti/Kconfig
@@ -7,6 +7,7 @@ menuconfig ARCH_STI
select PINCTRL
select PINCTRL_ST
select MFD_SYSCON
+ select ARCH_HAS_RESET_CONTROLLER
select MIGHT_HAVE_CACHE_L2X0
select HAVE_SMP
select HAVE_ARM_SCU if SMP
@@ -28,6 +29,7 @@ if ARCH_STI
config SOC_STIH415
bool "STiH415 STMicroelectronics Consumer Electronics family"
default y
+ select STIH415_RESET
help
This enables support for STMicroelectronics Digital Consumer
Electronics family StiH415 parts, primarily targeted at set-top-box
@@ -37,6 +39,7 @@ config SOC_STIH415
config SOC_STIH416
bool "STiH416 STMicroelectronics Consumer Electronics family"
default y
+ select STIH416_RESET
help
This enables support for STMicroelectronics Digital Consumer
Electronics family StiH416 parts, primarily targeted at set-top-box
--
1.7.9.5
^ permalink raw reply related [flat|nested] 72+ messages in thread
* [PATCH v2 6/6] ARM: STi: Add reset controller support to mach-sti Kconfig
@ 2014-02-03 14:29 ` srinivas.kandagatla
0 siblings, 0 replies; 72+ messages in thread
From: srinivas.kandagatla at st.com @ 2014-02-03 14:29 UTC (permalink / raw)
To: linux-arm-kernel
From: Stephen Gallimore <stephen.gallimore@st.com>
This patch selects reset controller support for ARCH_STI and
selects the reset controllers for STiH415 and STiH416 SoCs.
Signed-off-by: Stephen Gallimore <stephen.gallimore@st.com>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
---
arch/arm/mach-sti/Kconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-sti/Kconfig b/arch/arm/mach-sti/Kconfig
index d71654b..2550620 100644
--- a/arch/arm/mach-sti/Kconfig
+++ b/arch/arm/mach-sti/Kconfig
@@ -7,6 +7,7 @@ menuconfig ARCH_STI
select PINCTRL
select PINCTRL_ST
select MFD_SYSCON
+ select ARCH_HAS_RESET_CONTROLLER
select MIGHT_HAVE_CACHE_L2X0
select HAVE_SMP
select HAVE_ARM_SCU if SMP
@@ -28,6 +29,7 @@ if ARCH_STI
config SOC_STIH415
bool "STiH415 STMicroelectronics Consumer Electronics family"
default y
+ select STIH415_RESET
help
This enables support for STMicroelectronics Digital Consumer
Electronics family StiH415 parts, primarily targeted at set-top-box
@@ -37,6 +39,7 @@ config SOC_STIH415
config SOC_STIH416
bool "STiH416 STMicroelectronics Consumer Electronics family"
default y
+ select STIH416_RESET
help
This enables support for STMicroelectronics Digital Consumer
Electronics family StiH416 parts, primarily targeted at set-top-box
--
1.7.9.5
^ permalink raw reply related [flat|nested] 72+ messages in thread
* [PATCH v2 6/6] ARM: STi: Add reset controller support to mach-sti Kconfig
@ 2014-02-03 14:29 ` srinivas.kandagatla
0 siblings, 0 replies; 72+ messages in thread
From: srinivas.kandagatla @ 2014-02-03 14:29 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Philipp Zabel, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Rob Landley, Russell King,
Srinivas Kandagatla, Stuart Menefy, Grant Likely, devicetree,
linux-doc, linux-kernel, kernel, Arnd Bergmann,
stephen.gallimore, Olof Johansson
From: Stephen Gallimore <stephen.gallimore@st.com>
This patch selects reset controller support for ARCH_STI and
selects the reset controllers for STiH415 and STiH416 SoCs.
Signed-off-by: Stephen Gallimore <stephen.gallimore@st.com>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
---
arch/arm/mach-sti/Kconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-sti/Kconfig b/arch/arm/mach-sti/Kconfig
index d71654b..2550620 100644
--- a/arch/arm/mach-sti/Kconfig
+++ b/arch/arm/mach-sti/Kconfig
@@ -7,6 +7,7 @@ menuconfig ARCH_STI
select PINCTRL
select PINCTRL_ST
select MFD_SYSCON
+ select ARCH_HAS_RESET_CONTROLLER
select MIGHT_HAVE_CACHE_L2X0
select HAVE_SMP
select HAVE_ARM_SCU if SMP
@@ -28,6 +29,7 @@ if ARCH_STI
config SOC_STIH415
bool "STiH415 STMicroelectronics Consumer Electronics family"
default y
+ select STIH415_RESET
help
This enables support for STMicroelectronics Digital Consumer
Electronics family StiH415 parts, primarily targeted at set-top-box
@@ -37,6 +39,7 @@ config SOC_STIH415
config SOC_STIH416
bool "STiH416 STMicroelectronics Consumer Electronics family"
default y
+ select STIH416_RESET
help
This enables support for STMicroelectronics Digital Consumer
Electronics family StiH416 parts, primarily targeted at set-top-box
--
1.7.9.5
^ permalink raw reply related [flat|nested] 72+ messages in thread
* Re: [PATCH v2 0/6] ARM: STi reset controller support
2014-02-03 14:27 ` srinivas.kandagatla
(?)
@ 2014-02-05 9:28 ` Philipp Zabel
-1 siblings, 0 replies; 72+ messages in thread
From: Philipp Zabel @ 2014-02-05 9:28 UTC (permalink / raw)
To: srinivas.kandagatla
Cc: linux-arm-kernel, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Rob Landley, Russell King,
Stuart Menefy, Grant Likely, devicetree, linux-doc, linux-kernel,
kernel, Arnd Bergmann, stephen.gallimore, Olof Johansson
Hi Srinivas,
Am Montag, den 03.02.2014, 14:27 +0000 schrieb
srinivas.kandagatla@st.com:
> From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
>
> Hi All,
>
> This patch series adds reset controller support for STi SOC series STiH415 and
> STiH416. It adds support for both power down reset and soft reset controllers.
> On STi series SOCs reset lines are wired up to system configuration registers.
> Most of the IPs on STi SOCs are left in reset state, so this driver is very
> important for other drivers to use the IPs.
>
> Patch 01: Adds reset controller based on system configuration registers via
> regmap.
>
> Patch 02, 03: adds STiH415 and STiH416 reset controller drivers.
>
> Patch 04, 05: adds STiH415 and STiH416 soft reset controllers.
>
> The final patch 06 selects reset controller in mach-sti Kconfig.
>
> I would like get this driver in to 3.15, so that its possible to add dt
> support for other IPs with reset lines. Without this patchset its impossible
> to add DT support to IPs with reset lines as reset line definition is in
> common header file in include/dt-bindings/.
>
> This reset controller will be used by gmac, i2c and st-ir drivers.
>
>
> Comments?
the patchset looks good to me for the soft resets. But for the powerdown
bits I am wondering whether the reset controller API is the right
abstraction. Depending on whether those bits really just put the IPs
into reset or there is some power gating / sequencing involved,
shouldn't this rather be handled as a set of pm domains?
I see that for example on STiH415 there are both soft resets and
powerdown bits for USB[012].
regards
Philipp
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 0/6] ARM: STi reset controller support
@ 2014-02-05 9:28 ` Philipp Zabel
0 siblings, 0 replies; 72+ messages in thread
From: Philipp Zabel @ 2014-02-05 9:28 UTC (permalink / raw)
To: linux-arm-kernel
Hi Srinivas,
Am Montag, den 03.02.2014, 14:27 +0000 schrieb
srinivas.kandagatla at st.com:
> From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
>
> Hi All,
>
> This patch series adds reset controller support for STi SOC series STiH415 and
> STiH416. It adds support for both power down reset and soft reset controllers.
> On STi series SOCs reset lines are wired up to system configuration registers.
> Most of the IPs on STi SOCs are left in reset state, so this driver is very
> important for other drivers to use the IPs.
>
> Patch 01: Adds reset controller based on system configuration registers via
> regmap.
>
> Patch 02, 03: adds STiH415 and STiH416 reset controller drivers.
>
> Patch 04, 05: adds STiH415 and STiH416 soft reset controllers.
>
> The final patch 06 selects reset controller in mach-sti Kconfig.
>
> I would like get this driver in to 3.15, so that its possible to add dt
> support for other IPs with reset lines. Without this patchset its impossible
> to add DT support to IPs with reset lines as reset line definition is in
> common header file in include/dt-bindings/.
>
> This reset controller will be used by gmac, i2c and st-ir drivers.
>
>
> Comments?
the patchset looks good to me for the soft resets. But for the powerdown
bits I am wondering whether the reset controller API is the right
abstraction. Depending on whether those bits really just put the IPs
into reset or there is some power gating / sequencing involved,
shouldn't this rather be handled as a set of pm domains?
I see that for example on STiH415 there are both soft resets and
powerdown bits for USB[012].
regards
Philipp
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v2 0/6] ARM: STi reset controller support
@ 2014-02-05 9:28 ` Philipp Zabel
0 siblings, 0 replies; 72+ messages in thread
From: Philipp Zabel @ 2014-02-05 9:28 UTC (permalink / raw)
To: srinivas.kandagatla
Cc: Mark Rutland, devicetree, Russell King, kernel, Pawel Moll,
Ian Campbell, Olof Johansson, linux-doc, linux-kernel,
stephen.gallimore, Stuart Menefy, Rob Herring, Arnd Bergmann,
Rob Landley, Kumar Gala, Grant Likely, linux-arm-kernel
Hi Srinivas,
Am Montag, den 03.02.2014, 14:27 +0000 schrieb
srinivas.kandagatla@st.com:
> From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
>
> Hi All,
>
> This patch series adds reset controller support for STi SOC series STiH415 and
> STiH416. It adds support for both power down reset and soft reset controllers.
> On STi series SOCs reset lines are wired up to system configuration registers.
> Most of the IPs on STi SOCs are left in reset state, so this driver is very
> important for other drivers to use the IPs.
>
> Patch 01: Adds reset controller based on system configuration registers via
> regmap.
>
> Patch 02, 03: adds STiH415 and STiH416 reset controller drivers.
>
> Patch 04, 05: adds STiH415 and STiH416 soft reset controllers.
>
> The final patch 06 selects reset controller in mach-sti Kconfig.
>
> I would like get this driver in to 3.15, so that its possible to add dt
> support for other IPs with reset lines. Without this patchset its impossible
> to add DT support to IPs with reset lines as reset line definition is in
> common header file in include/dt-bindings/.
>
> This reset controller will be used by gmac, i2c and st-ir drivers.
>
>
> Comments?
the patchset looks good to me for the soft resets. But for the powerdown
bits I am wondering whether the reset controller API is the right
abstraction. Depending on whether those bits really just put the IPs
into reset or there is some power gating / sequencing involved,
shouldn't this rather be handled as a set of pm domains?
I see that for example on STiH415 there are both soft resets and
powerdown bits for USB[012].
regards
Philipp
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v2 0/6] ARM: STi reset controller support
2014-02-05 9:28 ` Philipp Zabel
(?)
@ 2014-02-07 12:54 ` srinivas kandagatla
-1 siblings, 0 replies; 72+ messages in thread
From: srinivas kandagatla @ 2014-02-07 12:54 UTC (permalink / raw)
To: Philipp Zabel
Cc: linux-arm-kernel, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Rob Landley, Russell King,
Stuart Menefy, Grant Likely, devicetree, linux-doc, linux-kernel,
kernel, Arnd Bergmann, stephen.gallimore, Olof Johansson
Hi Philipp,
Thankyou for looking at the patches.
On 05/02/14 09:28, Philipp Zabel wrote:
> Hi Srinivas,
>
...
>
> the patchset looks good to me for the soft resets. But for the powerdown
> bits I am wondering whether the reset controller API is the right
> abstraction. Depending on whether those bits really just put the IPs
> into reset or there is some power gating / sequencing involved,
> shouldn't this rather be handled as a set of pm domains?
The hardware name of these control signals into the devices is
slightly unfortunate and a bit misleading. We do not generally
have separate power domains for peripheral devices in our
current STB SoCs, in the sense that the voltage cannot actually be
removed from individual devices. In the USB case we believe the
powerdown signals internally gate off two of the three
incoming clocks to most of the USB controller's logic blocks,
essentially holding the device in a disabled (enable/disable
might have been a better name for the signal) state.
The primary requirement to manipulate these signals is to bring
the device out of its cold boot default powerdown/disabled/reset
(whatever you want to call it) state when the device is probed or
after a SoC wide power loss when resuming from PM_SUSPEND_MEM.
> I see that for example on STiH415 there are both soft resets and
> powerdown bits for USB[012].
Our IPs typically have two or sometimes three signals going into
them, controlled from outside of the IP block itself (typically using
SoC global system configuration registers) that you could view
as "reset-a-like"; that is toggling each of the signals puts the IP
into a state where it is in some way unusable and then back to
being useable again. The reset controller API appeared to be the
natural abstraction for the drivers to be given access to such control
signals, regardless of the precise effect the signals have on the
device's internal state.
With regards to sequencing between these signals; it is the case that
there is a likely sequencing because at least in the USB case it is
thought that the "powerdown" stops the clock going to the reset chain
logic. But we did not see that as an issue as the reset controller
framework allows for multiple named "reset" lines being defined for
a device through its DT attributes. The driver knows which signal
is which and what each does, because it asks for them by name;
therefore, it knows how to impose any required ordering when changing
the state of those signals.
Thanks,
srini
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 0/6] ARM: STi reset controller support
@ 2014-02-07 12:54 ` srinivas kandagatla
0 siblings, 0 replies; 72+ messages in thread
From: srinivas kandagatla @ 2014-02-07 12:54 UTC (permalink / raw)
To: linux-arm-kernel
Hi Philipp,
Thankyou for looking at the patches.
On 05/02/14 09:28, Philipp Zabel wrote:
> Hi Srinivas,
>
...
>
> the patchset looks good to me for the soft resets. But for the powerdown
> bits I am wondering whether the reset controller API is the right
> abstraction. Depending on whether those bits really just put the IPs
> into reset or there is some power gating / sequencing involved,
> shouldn't this rather be handled as a set of pm domains?
The hardware name of these control signals into the devices is
slightly unfortunate and a bit misleading. We do not generally
have separate power domains for peripheral devices in our
current STB SoCs, in the sense that the voltage cannot actually be
removed from individual devices. In the USB case we believe the
powerdown signals internally gate off two of the three
incoming clocks to most of the USB controller's logic blocks,
essentially holding the device in a disabled (enable/disable
might have been a better name for the signal) state.
The primary requirement to manipulate these signals is to bring
the device out of its cold boot default powerdown/disabled/reset
(whatever you want to call it) state when the device is probed or
after a SoC wide power loss when resuming from PM_SUSPEND_MEM.
> I see that for example on STiH415 there are both soft resets and
> powerdown bits for USB[012].
Our IPs typically have two or sometimes three signals going into
them, controlled from outside of the IP block itself (typically using
SoC global system configuration registers) that you could view
as "reset-a-like"; that is toggling each of the signals puts the IP
into a state where it is in some way unusable and then back to
being useable again. The reset controller API appeared to be the
natural abstraction for the drivers to be given access to such control
signals, regardless of the precise effect the signals have on the
device's internal state.
With regards to sequencing between these signals; it is the case that
there is a likely sequencing because at least in the USB case it is
thought that the "powerdown" stops the clock going to the reset chain
logic. But we did not see that as an issue as the reset controller
framework allows for multiple named "reset" lines being defined for
a device through its DT attributes. The driver knows which signal
is which and what each does, because it asks for them by name;
therefore, it knows how to impose any required ordering when changing
the state of those signals.
Thanks,
srini
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v2 0/6] ARM: STi reset controller support
@ 2014-02-07 12:54 ` srinivas kandagatla
0 siblings, 0 replies; 72+ messages in thread
From: srinivas kandagatla @ 2014-02-07 12:54 UTC (permalink / raw)
To: Philipp Zabel
Cc: Mark Rutland, devicetree, Russell King, kernel, Pawel Moll,
Ian Campbell, Olof Johansson, linux-doc, linux-kernel,
stephen.gallimore, Stuart Menefy, Rob Herring, Arnd Bergmann,
Rob Landley, Kumar Gala, Grant Likely, linux-arm-kernel
Hi Philipp,
Thankyou for looking at the patches.
On 05/02/14 09:28, Philipp Zabel wrote:
> Hi Srinivas,
>
...
>
> the patchset looks good to me for the soft resets. But for the powerdown
> bits I am wondering whether the reset controller API is the right
> abstraction. Depending on whether those bits really just put the IPs
> into reset or there is some power gating / sequencing involved,
> shouldn't this rather be handled as a set of pm domains?
The hardware name of these control signals into the devices is
slightly unfortunate and a bit misleading. We do not generally
have separate power domains for peripheral devices in our
current STB SoCs, in the sense that the voltage cannot actually be
removed from individual devices. In the USB case we believe the
powerdown signals internally gate off two of the three
incoming clocks to most of the USB controller's logic blocks,
essentially holding the device in a disabled (enable/disable
might have been a better name for the signal) state.
The primary requirement to manipulate these signals is to bring
the device out of its cold boot default powerdown/disabled/reset
(whatever you want to call it) state when the device is probed or
after a SoC wide power loss when resuming from PM_SUSPEND_MEM.
> I see that for example on STiH415 there are both soft resets and
> powerdown bits for USB[012].
Our IPs typically have two or sometimes three signals going into
them, controlled from outside of the IP block itself (typically using
SoC global system configuration registers) that you could view
as "reset-a-like"; that is toggling each of the signals puts the IP
into a state where it is in some way unusable and then back to
being useable again. The reset controller API appeared to be the
natural abstraction for the drivers to be given access to such control
signals, regardless of the precise effect the signals have on the
device's internal state.
With regards to sequencing between these signals; it is the case that
there is a likely sequencing because at least in the USB case it is
thought that the "powerdown" stops the clock going to the reset chain
logic. But we did not see that as an issue as the reset controller
framework allows for multiple named "reset" lines being defined for
a device through its DT attributes. The driver knows which signal
is which and what each does, because it asks for them by name;
therefore, it knows how to impose any required ordering when changing
the state of those signals.
Thanks,
srini
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v2 0/6] ARM: STi reset controller support
2014-02-07 12:54 ` srinivas kandagatla
(?)
@ 2014-02-19 13:57 ` Maxime Coquelin
-1 siblings, 0 replies; 72+ messages in thread
From: Maxime Coquelin @ 2014-02-19 13:57 UTC (permalink / raw)
To: srinivas kandagatla, Philipp Zabel
Cc: Mark Rutland, devicetree, Russell King, kernel, Pawel Moll,
Ian Campbell, Olof Johansson, linux-doc, linux-kernel,
stephen.gallimore, Rob Herring, Arnd Bergmann, Rob Landley,
Kumar Gala, Grant Likely, linux-arm-kernel
Hi Philipp,
On 02/07/2014 01:54 PM, srinivas kandagatla wrote:
> Hi Philipp,
> Thankyou for looking at the patches.
>
>
> On 05/02/14 09:28, Philipp Zabel wrote:
>> Hi Srinivas,
>>
> ...
>>
>> the patchset looks good to me for the soft resets. But for the powerdown
>> bits I am wondering whether the reset controller API is the right
>> abstraction. Depending on whether those bits really just put the IPs
>> into reset or there is some power gating / sequencing involved,
>> shouldn't this rather be handled as a set of pm domains?
>
> The hardware name of these control signals into the devices is
> slightly unfortunate and a bit misleading. We do not generally
> have separate power domains for peripheral devices in our
> current STB SoCs, in the sense that the voltage cannot actually be
> removed from individual devices. In the USB case we believe the
> powerdown signals internally gate off two of the three
> incoming clocks to most of the USB controller's logic blocks,
> essentially holding the device in a disabled (enable/disable
> might have been a better name for the signal) state.
>
> The primary requirement to manipulate these signals is to bring
> the device out of its cold boot default powerdown/disabled/reset
> (whatever you want to call it) state when the device is probed or
> after a SoC wide power loss when resuming from PM_SUSPEND_MEM.
>
>
>> I see that for example on STiH415 there are both soft resets and
>> powerdown bits for USB[012].
>
> Our IPs typically have two or sometimes three signals going into
> them, controlled from outside of the IP block itself (typically using
> SoC global system configuration registers) that you could view
> as "reset-a-like"; that is toggling each of the signals puts the IP
> into a state where it is in some way unusable and then back to
> being useable again. The reset controller API appeared to be the
> natural abstraction for the drivers to be given access to such control
> signals, regardless of the precise effect the signals have on the
> device's internal state.
>
> With regards to sequencing between these signals; it is the case that
> there is a likely sequencing because at least in the USB case it is
> thought that the "powerdown" stops the clock going to the reset chain
> logic. But we did not see that as an issue as the reset controller
> framework allows for multiple named "reset" lines being defined for
> a device through its DT attributes. The driver knows which signal
> is which and what each does, because it asks for them by name;
> therefore, it knows how to impose any required ordering when changing
> the state of those signals.
>
Did Srini's explanations convinced you?
If so, could you queue the series for v3.15?
Thanks,
Maxime
>
> Thanks,
> srini
>
>
> _______________________________________________
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 0/6] ARM: STi reset controller support
@ 2014-02-19 13:57 ` Maxime Coquelin
0 siblings, 0 replies; 72+ messages in thread
From: Maxime Coquelin @ 2014-02-19 13:57 UTC (permalink / raw)
To: linux-arm-kernel
Hi Philipp,
On 02/07/2014 01:54 PM, srinivas kandagatla wrote:
> Hi Philipp,
> Thankyou for looking at the patches.
>
>
> On 05/02/14 09:28, Philipp Zabel wrote:
>> Hi Srinivas,
>>
> ...
>>
>> the patchset looks good to me for the soft resets. But for the powerdown
>> bits I am wondering whether the reset controller API is the right
>> abstraction. Depending on whether those bits really just put the IPs
>> into reset or there is some power gating / sequencing involved,
>> shouldn't this rather be handled as a set of pm domains?
>
> The hardware name of these control signals into the devices is
> slightly unfortunate and a bit misleading. We do not generally
> have separate power domains for peripheral devices in our
> current STB SoCs, in the sense that the voltage cannot actually be
> removed from individual devices. In the USB case we believe the
> powerdown signals internally gate off two of the three
> incoming clocks to most of the USB controller's logic blocks,
> essentially holding the device in a disabled (enable/disable
> might have been a better name for the signal) state.
>
> The primary requirement to manipulate these signals is to bring
> the device out of its cold boot default powerdown/disabled/reset
> (whatever you want to call it) state when the device is probed or
> after a SoC wide power loss when resuming from PM_SUSPEND_MEM.
>
>
>> I see that for example on STiH415 there are both soft resets and
>> powerdown bits for USB[012].
>
> Our IPs typically have two or sometimes three signals going into
> them, controlled from outside of the IP block itself (typically using
> SoC global system configuration registers) that you could view
> as "reset-a-like"; that is toggling each of the signals puts the IP
> into a state where it is in some way unusable and then back to
> being useable again. The reset controller API appeared to be the
> natural abstraction for the drivers to be given access to such control
> signals, regardless of the precise effect the signals have on the
> device's internal state.
>
> With regards to sequencing between these signals; it is the case that
> there is a likely sequencing because at least in the USB case it is
> thought that the "powerdown" stops the clock going to the reset chain
> logic. But we did not see that as an issue as the reset controller
> framework allows for multiple named "reset" lines being defined for
> a device through its DT attributes. The driver knows which signal
> is which and what each does, because it asks for them by name;
> therefore, it knows how to impose any required ordering when changing
> the state of those signals.
>
Did Srini's explanations convinced you?
If so, could you queue the series for v3.15?
Thanks,
Maxime
>
> Thanks,
> srini
>
>
> _______________________________________________
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v2 0/6] ARM: STi reset controller support
@ 2014-02-19 13:57 ` Maxime Coquelin
0 siblings, 0 replies; 72+ messages in thread
From: Maxime Coquelin @ 2014-02-19 13:57 UTC (permalink / raw)
To: srinivas kandagatla, Philipp Zabel
Cc: Mark Rutland, devicetree, Russell King, kernel, Pawel Moll,
Ian Campbell, linux-doc, linux-kernel, stephen.gallimore,
Grant Likely, Rob Herring, Arnd Bergmann, Rob Landley,
Kumar Gala, Olof Johansson, linux-arm-kernel
Hi Philipp,
On 02/07/2014 01:54 PM, srinivas kandagatla wrote:
> Hi Philipp,
> Thankyou for looking at the patches.
>
>
> On 05/02/14 09:28, Philipp Zabel wrote:
>> Hi Srinivas,
>>
> ...
>>
>> the patchset looks good to me for the soft resets. But for the powerdown
>> bits I am wondering whether the reset controller API is the right
>> abstraction. Depending on whether those bits really just put the IPs
>> into reset or there is some power gating / sequencing involved,
>> shouldn't this rather be handled as a set of pm domains?
>
> The hardware name of these control signals into the devices is
> slightly unfortunate and a bit misleading. We do not generally
> have separate power domains for peripheral devices in our
> current STB SoCs, in the sense that the voltage cannot actually be
> removed from individual devices. In the USB case we believe the
> powerdown signals internally gate off two of the three
> incoming clocks to most of the USB controller's logic blocks,
> essentially holding the device in a disabled (enable/disable
> might have been a better name for the signal) state.
>
> The primary requirement to manipulate these signals is to bring
> the device out of its cold boot default powerdown/disabled/reset
> (whatever you want to call it) state when the device is probed or
> after a SoC wide power loss when resuming from PM_SUSPEND_MEM.
>
>
>> I see that for example on STiH415 there are both soft resets and
>> powerdown bits for USB[012].
>
> Our IPs typically have two or sometimes three signals going into
> them, controlled from outside of the IP block itself (typically using
> SoC global system configuration registers) that you could view
> as "reset-a-like"; that is toggling each of the signals puts the IP
> into a state where it is in some way unusable and then back to
> being useable again. The reset controller API appeared to be the
> natural abstraction for the drivers to be given access to such control
> signals, regardless of the precise effect the signals have on the
> device's internal state.
>
> With regards to sequencing between these signals; it is the case that
> there is a likely sequencing because at least in the USB case it is
> thought that the "powerdown" stops the clock going to the reset chain
> logic. But we did not see that as an issue as the reset controller
> framework allows for multiple named "reset" lines being defined for
> a device through its DT attributes. The driver knows which signal
> is which and what each does, because it asks for them by name;
> therefore, it knows how to impose any required ordering when changing
> the state of those signals.
>
Did Srini's explanations convinced you?
If so, could you queue the series for v3.15?
Thanks,
Maxime
>
> Thanks,
> srini
>
>
> _______________________________________________
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v2 0/6] ARM: STi reset controller support
@ 2014-02-24 10:33 ` Philipp Zabel
0 siblings, 0 replies; 72+ messages in thread
From: Philipp Zabel @ 2014-02-24 10:33 UTC (permalink / raw)
To: Maxime Coquelin
Cc: srinivas kandagatla, Mark Rutland, devicetree, Russell King,
kernel, Pawel Moll, Ian Campbell, Olof Johansson, linux-doc,
linux-kernel, stephen.gallimore, Rob Herring, Arnd Bergmann,
Rob Landley, Kumar Gala, Grant Likely, linux-arm-kernel
Hi Maxime,
Am Mittwoch, den 19.02.2014, 14:57 +0100 schrieb Maxime Coquelin:
> Hi Philipp,
>
> On 02/07/2014 01:54 PM, srinivas kandagatla wrote:
> > Hi Philipp,
> > Thankyou for looking at the patches.
> >
> >
> > On 05/02/14 09:28, Philipp Zabel wrote:
> >> Hi Srinivas,
> >>
> > ...
> >>
> >> the patchset looks good to me for the soft resets. But for the powerdown
> >> bits I am wondering whether the reset controller API is the right
> >> abstraction. Depending on whether those bits really just put the IPs
> >> into reset or there is some power gating / sequencing involved,
> >> shouldn't this rather be handled as a set of pm domains?
> >
> > The hardware name of these control signals into the devices is
> > slightly unfortunate and a bit misleading. We do not generally
> > have separate power domains for peripheral devices in our
> > current STB SoCs, in the sense that the voltage cannot actually be
> > removed from individual devices. In the USB case we believe the
> > powerdown signals internally gate off two of the three
> > incoming clocks to most of the USB controller's logic blocks,
> > essentially holding the device in a disabled (enable/disable
> > might have been a better name for the signal) state.
> >
> > The primary requirement to manipulate these signals is to bring
> > the device out of its cold boot default powerdown/disabled/reset
> > (whatever you want to call it) state when the device is probed or
> > after a SoC wide power loss when resuming from PM_SUSPEND_MEM.
> >
> >
> >> I see that for example on STiH415 there are both soft resets and
> >> powerdown bits for USB[012].
> >
> > Our IPs typically have two or sometimes three signals going into
> > them, controlled from outside of the IP block itself (typically using
> > SoC global system configuration registers) that you could view
> > as "reset-a-like"; that is toggling each of the signals puts the IP
> > into a state where it is in some way unusable and then back to
> > being useable again. The reset controller API appeared to be the
> > natural abstraction for the drivers to be given access to such control
> > signals, regardless of the precise effect the signals have on the
> > device's internal state.
> >
> > With regards to sequencing between these signals; it is the case that
> > there is a likely sequencing because at least in the USB case it is
> > thought that the "powerdown" stops the clock going to the reset chain
> > logic. But we did not see that as an issue as the reset controller
> > framework allows for multiple named "reset" lines being defined for
> > a device through its DT attributes. The driver knows which signal
> > is which and what each does, because it asks for them by name;
> > therefore, it knows how to impose any required ordering when changing
> > the state of those signals.
> >
>
> Did Srini's explanations convinced you?
>
> If so, could you queue the series for v3.15?
to be honest, I'm not comfortable with this explanation. If the
"powerdown" bits only gate the clocks to those modules, calling it a
reset control is clearly the wrong abstraction. If that is the case,
couldn't you handle those bits via the clock framework?
If on the other hand these powerdown bits also trigger reset machinery,
such that asserting and deasserting that bit will change the module's
internal state, I could be convinced to queue them like this.
regards
Philipp
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 0/6] ARM: STi reset controller support
@ 2014-02-24 10:33 ` Philipp Zabel
0 siblings, 0 replies; 72+ messages in thread
From: Philipp Zabel @ 2014-02-24 10:33 UTC (permalink / raw)
To: linux-arm-kernel
Hi Maxime,
Am Mittwoch, den 19.02.2014, 14:57 +0100 schrieb Maxime Coquelin:
> Hi Philipp,
>
> On 02/07/2014 01:54 PM, srinivas kandagatla wrote:
> > Hi Philipp,
> > Thankyou for looking at the patches.
> >
> >
> > On 05/02/14 09:28, Philipp Zabel wrote:
> >> Hi Srinivas,
> >>
> > ...
> >>
> >> the patchset looks good to me for the soft resets. But for the powerdown
> >> bits I am wondering whether the reset controller API is the right
> >> abstraction. Depending on whether those bits really just put the IPs
> >> into reset or there is some power gating / sequencing involved,
> >> shouldn't this rather be handled as a set of pm domains?
> >
> > The hardware name of these control signals into the devices is
> > slightly unfortunate and a bit misleading. We do not generally
> > have separate power domains for peripheral devices in our
> > current STB SoCs, in the sense that the voltage cannot actually be
> > removed from individual devices. In the USB case we believe the
> > powerdown signals internally gate off two of the three
> > incoming clocks to most of the USB controller's logic blocks,
> > essentially holding the device in a disabled (enable/disable
> > might have been a better name for the signal) state.
> >
> > The primary requirement to manipulate these signals is to bring
> > the device out of its cold boot default powerdown/disabled/reset
> > (whatever you want to call it) state when the device is probed or
> > after a SoC wide power loss when resuming from PM_SUSPEND_MEM.
> >
> >
> >> I see that for example on STiH415 there are both soft resets and
> >> powerdown bits for USB[012].
> >
> > Our IPs typically have two or sometimes three signals going into
> > them, controlled from outside of the IP block itself (typically using
> > SoC global system configuration registers) that you could view
> > as "reset-a-like"; that is toggling each of the signals puts the IP
> > into a state where it is in some way unusable and then back to
> > being useable again. The reset controller API appeared to be the
> > natural abstraction for the drivers to be given access to such control
> > signals, regardless of the precise effect the signals have on the
> > device's internal state.
> >
> > With regards to sequencing between these signals; it is the case that
> > there is a likely sequencing because at least in the USB case it is
> > thought that the "powerdown" stops the clock going to the reset chain
> > logic. But we did not see that as an issue as the reset controller
> > framework allows for multiple named "reset" lines being defined for
> > a device through its DT attributes. The driver knows which signal
> > is which and what each does, because it asks for them by name;
> > therefore, it knows how to impose any required ordering when changing
> > the state of those signals.
> >
>
> Did Srini's explanations convinced you?
>
> If so, could you queue the series for v3.15?
to be honest, I'm not comfortable with this explanation. If the
"powerdown" bits only gate the clocks to those modules, calling it a
reset control is clearly the wrong abstraction. If that is the case,
couldn't you handle those bits via the clock framework?
If on the other hand these powerdown bits also trigger reset machinery,
such that asserting and deasserting that bit will change the module's
internal state, I could be convinced to queue them like this.
regards
Philipp
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v2 0/6] ARM: STi reset controller support
@ 2014-02-24 10:33 ` Philipp Zabel
0 siblings, 0 replies; 72+ messages in thread
From: Philipp Zabel @ 2014-02-24 10:33 UTC (permalink / raw)
To: Maxime Coquelin
Cc: srinivas kandagatla, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King,
kernel-F5mvAk5X5gdBDgjK7y7TUQ, Pawel Moll, Ian Campbell,
Olof Johansson, linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
stephen.gallimore-qxv4g6HH51o, Rob Herring, Arnd Bergmann,
Rob Landley, Kumar Gala, Grant Likely,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Hi Maxime,
Am Mittwoch, den 19.02.2014, 14:57 +0100 schrieb Maxime Coquelin:
> Hi Philipp,
>
> On 02/07/2014 01:54 PM, srinivas kandagatla wrote:
> > Hi Philipp,
> > Thankyou for looking at the patches.
> >
> >
> > On 05/02/14 09:28, Philipp Zabel wrote:
> >> Hi Srinivas,
> >>
> > ...
> >>
> >> the patchset looks good to me for the soft resets. But for the powerdown
> >> bits I am wondering whether the reset controller API is the right
> >> abstraction. Depending on whether those bits really just put the IPs
> >> into reset or there is some power gating / sequencing involved,
> >> shouldn't this rather be handled as a set of pm domains?
> >
> > The hardware name of these control signals into the devices is
> > slightly unfortunate and a bit misleading. We do not generally
> > have separate power domains for peripheral devices in our
> > current STB SoCs, in the sense that the voltage cannot actually be
> > removed from individual devices. In the USB case we believe the
> > powerdown signals internally gate off two of the three
> > incoming clocks to most of the USB controller's logic blocks,
> > essentially holding the device in a disabled (enable/disable
> > might have been a better name for the signal) state.
> >
> > The primary requirement to manipulate these signals is to bring
> > the device out of its cold boot default powerdown/disabled/reset
> > (whatever you want to call it) state when the device is probed or
> > after a SoC wide power loss when resuming from PM_SUSPEND_MEM.
> >
> >
> >> I see that for example on STiH415 there are both soft resets and
> >> powerdown bits for USB[012].
> >
> > Our IPs typically have two or sometimes three signals going into
> > them, controlled from outside of the IP block itself (typically using
> > SoC global system configuration registers) that you could view
> > as "reset-a-like"; that is toggling each of the signals puts the IP
> > into a state where it is in some way unusable and then back to
> > being useable again. The reset controller API appeared to be the
> > natural abstraction for the drivers to be given access to such control
> > signals, regardless of the precise effect the signals have on the
> > device's internal state.
> >
> > With regards to sequencing between these signals; it is the case that
> > there is a likely sequencing because at least in the USB case it is
> > thought that the "powerdown" stops the clock going to the reset chain
> > logic. But we did not see that as an issue as the reset controller
> > framework allows for multiple named "reset" lines being defined for
> > a device through its DT attributes. The driver knows which signal
> > is which and what each does, because it asks for them by name;
> > therefore, it knows how to impose any required ordering when changing
> > the state of those signals.
> >
>
> Did Srini's explanations convinced you?
>
> If so, could you queue the series for v3.15?
to be honest, I'm not comfortable with this explanation. If the
"powerdown" bits only gate the clocks to those modules, calling it a
reset control is clearly the wrong abstraction. If that is the case,
couldn't you handle those bits via the clock framework?
If on the other hand these powerdown bits also trigger reset machinery,
such that asserting and deasserting that bit will change the module's
internal state, I could be convinced to queue them like this.
regards
Philipp
--
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] 72+ messages in thread
* Re: [PATCH v2 0/6] ARM: STi reset controller support
2014-02-24 10:33 ` Philipp Zabel
(?)
@ 2014-02-24 14:03 ` srinivas kandagatla
-1 siblings, 0 replies; 72+ messages in thread
From: srinivas kandagatla @ 2014-02-24 14:03 UTC (permalink / raw)
To: Philipp Zabel, Maxime Coquelin
Cc: Mark Rutland, devicetree, Russell King, kernel, Pawel Moll,
Ian Campbell, Olof Johansson, linux-doc, linux-kernel,
stephen.gallimore, Rob Herring, Arnd Bergmann, Rob Landley,
Kumar Gala, Grant Likely, linux-arm-kernel
Thanks Philipp for your comments,
On 24/02/14 10:33, Philipp Zabel wrote:
>> > Did Srini's explanations convinced you?
>> >
>> > If so, could you queue the series for v3.15?
> to be honest, I'm not comfortable with this explanation. If the
> "powerdown" bits only gate the clocks to those modules, calling it a
> reset control is clearly the wrong abstraction. If that is the case,
> couldn't you handle those bits via the clock framework?
I just had a re-look at the IPs specs for more information on where
these power-down signals are actually terminating on the IP side.
For example: ST-Synopsis Ethernet GMAC IP has two pins
power_down_req[IN] and power_down_ack[OUT]. power_down_req is used by
the software to either put the IP in powerdown or bring it out of
powerdown state.
The IP itself drives power_down_ack to indicate when the power down
request is successfully finished. For power_down/power_up request the IP
will change the internal state accordingly including powering up/down
its internal blocks and/or clock gating.
> If on the other hand these powerdown bits also trigger reset machinery,
> such that asserting and deasserting that bit will change the module's
> internal state, I could be convinced to queue them like this.
This is true with ST IPs, these lines change the state of the IP as
described above. Reset framework seems to fits in very well with this
behavior rather than power-domains or clock framework.
Thanks,
srini
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 0/6] ARM: STi reset controller support
@ 2014-02-24 14:03 ` srinivas kandagatla
0 siblings, 0 replies; 72+ messages in thread
From: srinivas kandagatla @ 2014-02-24 14:03 UTC (permalink / raw)
To: linux-arm-kernel
Thanks Philipp for your comments,
On 24/02/14 10:33, Philipp Zabel wrote:
>> > Did Srini's explanations convinced you?
>> >
>> > If so, could you queue the series for v3.15?
> to be honest, I'm not comfortable with this explanation. If the
> "powerdown" bits only gate the clocks to those modules, calling it a
> reset control is clearly the wrong abstraction. If that is the case,
> couldn't you handle those bits via the clock framework?
I just had a re-look at the IPs specs for more information on where
these power-down signals are actually terminating on the IP side.
For example: ST-Synopsis Ethernet GMAC IP has two pins
power_down_req[IN] and power_down_ack[OUT]. power_down_req is used by
the software to either put the IP in powerdown or bring it out of
powerdown state.
The IP itself drives power_down_ack to indicate when the power down
request is successfully finished. For power_down/power_up request the IP
will change the internal state accordingly including powering up/down
its internal blocks and/or clock gating.
> If on the other hand these powerdown bits also trigger reset machinery,
> such that asserting and deasserting that bit will change the module's
> internal state, I could be convinced to queue them like this.
This is true with ST IPs, these lines change the state of the IP as
described above. Reset framework seems to fits in very well with this
behavior rather than power-domains or clock framework.
Thanks,
srini
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v2 0/6] ARM: STi reset controller support
@ 2014-02-24 14:03 ` srinivas kandagatla
0 siblings, 0 replies; 72+ messages in thread
From: srinivas kandagatla @ 2014-02-24 14:03 UTC (permalink / raw)
To: Philipp Zabel, Maxime Coquelin
Cc: Mark Rutland, devicetree, Russell King, kernel, Pawel Moll,
Ian Campbell, linux-doc, linux-kernel, stephen.gallimore,
Grant Likely, Rob Herring, Arnd Bergmann, Rob Landley,
Kumar Gala, Olof Johansson, linux-arm-kernel
Thanks Philipp for your comments,
On 24/02/14 10:33, Philipp Zabel wrote:
>> > Did Srini's explanations convinced you?
>> >
>> > If so, could you queue the series for v3.15?
> to be honest, I'm not comfortable with this explanation. If the
> "powerdown" bits only gate the clocks to those modules, calling it a
> reset control is clearly the wrong abstraction. If that is the case,
> couldn't you handle those bits via the clock framework?
I just had a re-look at the IPs specs for more information on where
these power-down signals are actually terminating on the IP side.
For example: ST-Synopsis Ethernet GMAC IP has two pins
power_down_req[IN] and power_down_ack[OUT]. power_down_req is used by
the software to either put the IP in powerdown or bring it out of
powerdown state.
The IP itself drives power_down_ack to indicate when the power down
request is successfully finished. For power_down/power_up request the IP
will change the internal state accordingly including powering up/down
its internal blocks and/or clock gating.
> If on the other hand these powerdown bits also trigger reset machinery,
> such that asserting and deasserting that bit will change the module's
> internal state, I could be convinced to queue them like this.
This is true with ST IPs, these lines change the state of the IP as
described above. Reset framework seems to fits in very well with this
behavior rather than power-domains or clock framework.
Thanks,
srini
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v2 0/6] ARM: STi reset controller support
@ 2014-02-24 15:16 ` Philipp Zabel
0 siblings, 0 replies; 72+ messages in thread
From: Philipp Zabel @ 2014-02-24 15:16 UTC (permalink / raw)
To: srinivas kandagatla
Cc: Maxime Coquelin, Mark Rutland, devicetree, Russell King, kernel,
Pawel Moll, Ian Campbell, Olof Johansson, linux-doc,
linux-kernel, stephen.gallimore, Rob Herring, Arnd Bergmann,
Rob Landley, Kumar Gala, Grant Likely, linux-arm-kernel
Hi Srinivas,
Am Montag, den 24.02.2014, 14:03 +0000 schrieb srinivas kandagatla:
> Thanks Philipp for your comments,
>
> On 24/02/14 10:33, Philipp Zabel wrote:
> >> > Did Srini's explanations convinced you?
> >> >
> >> > If so, could you queue the series for v3.15?
> > to be honest, I'm not comfortable with this explanation. If the
> > "powerdown" bits only gate the clocks to those modules, calling it a
> > reset control is clearly the wrong abstraction. If that is the case,
> > couldn't you handle those bits via the clock framework?
> I just had a re-look at the IPs specs for more information on where
> these power-down signals are actually terminating on the IP side.
>
> For example: ST-Synopsis Ethernet GMAC IP has two pins
> power_down_req[IN] and power_down_ack[OUT]. power_down_req is used by
> the software to either put the IP in powerdown or bring it out of
> powerdown state.
Now I'm a bit confused. There is no mention of GMAC in your patches,
and for ETH[01] they contain only the SOFTRESET bits. I have no issue
with the SOFTRESETs.
> The IP itself drives power_down_ack to indicate when the power down
> request is successfully finished. For power_down/power_up request the IP
> will change the internal state accordingly including powering up/down
> its internal blocks and/or clock gating.
>
> > If on the other hand these powerdown bits also trigger reset machinery,
> > such that asserting and deasserting that bit will change the module's
> > internal state, I could be convinced to queue them like this.
> This is true with ST IPs, these lines change the state of the IP as
> described above. Reset framework seems to fits in very well with this
> behavior rather than power-domains or clock framework.
If you put the IP in power down when it is idle, and then power it up
again, will the IP registers have kept their previous state?
regards
Philipp
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 0/6] ARM: STi reset controller support
@ 2014-02-24 15:16 ` Philipp Zabel
0 siblings, 0 replies; 72+ messages in thread
From: Philipp Zabel @ 2014-02-24 15:16 UTC (permalink / raw)
To: linux-arm-kernel
Hi Srinivas,
Am Montag, den 24.02.2014, 14:03 +0000 schrieb srinivas kandagatla:
> Thanks Philipp for your comments,
>
> On 24/02/14 10:33, Philipp Zabel wrote:
> >> > Did Srini's explanations convinced you?
> >> >
> >> > If so, could you queue the series for v3.15?
> > to be honest, I'm not comfortable with this explanation. If the
> > "powerdown" bits only gate the clocks to those modules, calling it a
> > reset control is clearly the wrong abstraction. If that is the case,
> > couldn't you handle those bits via the clock framework?
> I just had a re-look at the IPs specs for more information on where
> these power-down signals are actually terminating on the IP side.
>
> For example: ST-Synopsis Ethernet GMAC IP has two pins
> power_down_req[IN] and power_down_ack[OUT]. power_down_req is used by
> the software to either put the IP in powerdown or bring it out of
> powerdown state.
Now I'm a bit confused. There is no mention of GMAC in your patches,
and for ETH[01] they contain only the SOFTRESET bits. I have no issue
with the SOFTRESETs.
> The IP itself drives power_down_ack to indicate when the power down
> request is successfully finished. For power_down/power_up request the IP
> will change the internal state accordingly including powering up/down
> its internal blocks and/or clock gating.
>
> > If on the other hand these powerdown bits also trigger reset machinery,
> > such that asserting and deasserting that bit will change the module's
> > internal state, I could be convinced to queue them like this.
> This is true with ST IPs, these lines change the state of the IP as
> described above. Reset framework seems to fits in very well with this
> behavior rather than power-domains or clock framework.
If you put the IP in power down when it is idle, and then power it up
again, will the IP registers have kept their previous state?
regards
Philipp
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v2 0/6] ARM: STi reset controller support
@ 2014-02-24 15:16 ` Philipp Zabel
0 siblings, 0 replies; 72+ messages in thread
From: Philipp Zabel @ 2014-02-24 15:16 UTC (permalink / raw)
To: srinivas kandagatla
Cc: Maxime Coquelin, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
Russell King, kernel-F5mvAk5X5gdBDgjK7y7TUQ, Pawel Moll,
Ian Campbell, Olof Johansson, linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
stephen.gallimore-qxv4g6HH51o, Rob Herring, Arnd Bergmann,
Rob Landley, Kumar Gala, Grant Likely,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Hi Srinivas,
Am Montag, den 24.02.2014, 14:03 +0000 schrieb srinivas kandagatla:
> Thanks Philipp for your comments,
>
> On 24/02/14 10:33, Philipp Zabel wrote:
> >> > Did Srini's explanations convinced you?
> >> >
> >> > If so, could you queue the series for v3.15?
> > to be honest, I'm not comfortable with this explanation. If the
> > "powerdown" bits only gate the clocks to those modules, calling it a
> > reset control is clearly the wrong abstraction. If that is the case,
> > couldn't you handle those bits via the clock framework?
> I just had a re-look at the IPs specs for more information on where
> these power-down signals are actually terminating on the IP side.
>
> For example: ST-Synopsis Ethernet GMAC IP has two pins
> power_down_req[IN] and power_down_ack[OUT]. power_down_req is used by
> the software to either put the IP in powerdown or bring it out of
> powerdown state.
Now I'm a bit confused. There is no mention of GMAC in your patches,
and for ETH[01] they contain only the SOFTRESET bits. I have no issue
with the SOFTRESETs.
> The IP itself drives power_down_ack to indicate when the power down
> request is successfully finished. For power_down/power_up request the IP
> will change the internal state accordingly including powering up/down
> its internal blocks and/or clock gating.
>
> > If on the other hand these powerdown bits also trigger reset machinery,
> > such that asserting and deasserting that bit will change the module's
> > internal state, I could be convinced to queue them like this.
> This is true with ST IPs, these lines change the state of the IP as
> described above. Reset framework seems to fits in very well with this
> behavior rather than power-domains or clock framework.
If you put the IP in power down when it is idle, and then power it up
again, will the IP registers have kept their previous state?
regards
Philipp
--
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] 72+ messages in thread
* Re: [PATCH v2 0/6] ARM: STi reset controller support
2014-02-24 15:16 ` Philipp Zabel
(?)
@ 2014-02-25 9:08 ` srinivas kandagatla
-1 siblings, 0 replies; 72+ messages in thread
From: srinivas kandagatla @ 2014-02-25 9:08 UTC (permalink / raw)
To: Philipp Zabel
Cc: Maxime Coquelin, Mark Rutland, devicetree, Russell King, kernel,
Pawel Moll, Ian Campbell, Olof Johansson, linux-doc,
linux-kernel, stephen.gallimore, Rob Herring, Arnd Bergmann,
Rob Landley, Kumar Gala, Grant Likely, linux-arm-kernel
On 24/02/14 15:16, Philipp Zabel wrote:
> Hi Srinivas,
>
> Am Montag, den 24.02.2014, 14:03 +0000 schrieb srinivas kandagatla:
>> Thanks Philipp for your comments,
>>
>> On 24/02/14 10:33, Philipp Zabel wrote:
>>>>> Did Srini's explanations convinced you?
>>>>>
>>>>> If so, could you queue the series for v3.15?
>>> to be honest, I'm not comfortable with this explanation. If the
>>> "powerdown" bits only gate the clocks to those modules, calling it a
>>> reset control is clearly the wrong abstraction. If that is the case,
>>> couldn't you handle those bits via the clock framework?
>> I just had a re-look at the IPs specs for more information on where
>> these power-down signals are actually terminating on the IP side.
>>
>> For example: ST-Synopsis Ethernet GMAC IP has two pins
>> power_down_req[IN] and power_down_ack[OUT]. power_down_req is used by
>> the software to either put the IP in powerdown or bring it out of
>> powerdown state.
>
> Now I'm a bit confused. There is no mention of GMAC in your patches,
> and for ETH[01] they contain only the SOFTRESET bits. I have no issue
> with the SOFTRESETs.
Yes, GMAC was a bad example indeed. However this same logic applies to
the USB IP as well.
GMAC power-down-reset can be added to the power-down-reset list for
consistency.
We did not define the power-down-reset for GMAC because the reset state
of GMAC will not be in power down. softreset should be enough to bring
the IP in to a usable state. So the software never drives the power
down-request but instead uses softreset in this particular case.
>
>> The IP itself drives power_down_ack to indicate when the power down
>> request is successfully finished. For power_down/power_up request the IP
>> will change the internal state accordingly including powering up/down
>> its internal blocks and/or clock gating.
>>
>>> If on the other hand these powerdown bits also trigger reset machinery,
>>> such that asserting and deasserting that bit will change the module's
>>> internal state, I could be convinced to queue them like this.
>> This is true with ST IPs, these lines change the state of the IP as
>> described above. Reset framework seems to fits in very well with this
>> behavior rather than power-domains or clock framework.
>
> If you put the IP in power down when it is idle, and then power it up
> again, will the IP registers have kept their previous state?
No, the context is lost, the IP needs re-initialization.
Thanks,
srini
>
> regards
> Philipp
>
>
>
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 0/6] ARM: STi reset controller support
@ 2014-02-25 9:08 ` srinivas kandagatla
0 siblings, 0 replies; 72+ messages in thread
From: srinivas kandagatla @ 2014-02-25 9:08 UTC (permalink / raw)
To: linux-arm-kernel
On 24/02/14 15:16, Philipp Zabel wrote:
> Hi Srinivas,
>
> Am Montag, den 24.02.2014, 14:03 +0000 schrieb srinivas kandagatla:
>> Thanks Philipp for your comments,
>>
>> On 24/02/14 10:33, Philipp Zabel wrote:
>>>>> Did Srini's explanations convinced you?
>>>>>
>>>>> If so, could you queue the series for v3.15?
>>> to be honest, I'm not comfortable with this explanation. If the
>>> "powerdown" bits only gate the clocks to those modules, calling it a
>>> reset control is clearly the wrong abstraction. If that is the case,
>>> couldn't you handle those bits via the clock framework?
>> I just had a re-look at the IPs specs for more information on where
>> these power-down signals are actually terminating on the IP side.
>>
>> For example: ST-Synopsis Ethernet GMAC IP has two pins
>> power_down_req[IN] and power_down_ack[OUT]. power_down_req is used by
>> the software to either put the IP in powerdown or bring it out of
>> powerdown state.
>
> Now I'm a bit confused. There is no mention of GMAC in your patches,
> and for ETH[01] they contain only the SOFTRESET bits. I have no issue
> with the SOFTRESETs.
Yes, GMAC was a bad example indeed. However this same logic applies to
the USB IP as well.
GMAC power-down-reset can be added to the power-down-reset list for
consistency.
We did not define the power-down-reset for GMAC because the reset state
of GMAC will not be in power down. softreset should be enough to bring
the IP in to a usable state. So the software never drives the power
down-request but instead uses softreset in this particular case.
>
>> The IP itself drives power_down_ack to indicate when the power down
>> request is successfully finished. For power_down/power_up request the IP
>> will change the internal state accordingly including powering up/down
>> its internal blocks and/or clock gating.
>>
>>> If on the other hand these powerdown bits also trigger reset machinery,
>>> such that asserting and deasserting that bit will change the module's
>>> internal state, I could be convinced to queue them like this.
>> This is true with ST IPs, these lines change the state of the IP as
>> described above. Reset framework seems to fits in very well with this
>> behavior rather than power-domains or clock framework.
>
> If you put the IP in power down when it is idle, and then power it up
> again, will the IP registers have kept their previous state?
No, the context is lost, the IP needs re-initialization.
Thanks,
srini
>
> regards
> Philipp
>
>
>
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v2 0/6] ARM: STi reset controller support
@ 2014-02-25 9:08 ` srinivas kandagatla
0 siblings, 0 replies; 72+ messages in thread
From: srinivas kandagatla @ 2014-02-25 9:08 UTC (permalink / raw)
To: Philipp Zabel
Cc: Maxime Coquelin, Mark Rutland, devicetree, Russell King, kernel,
Pawel Moll, Ian Campbell, Olof Johansson, linux-doc,
linux-kernel, stephen.gallimore, Rob Herring, Arnd Bergmann,
Rob Landley, Kumar Gala, Grant Likely, linux-arm-kernel
On 24/02/14 15:16, Philipp Zabel wrote:
> Hi Srinivas,
>
> Am Montag, den 24.02.2014, 14:03 +0000 schrieb srinivas kandagatla:
>> Thanks Philipp for your comments,
>>
>> On 24/02/14 10:33, Philipp Zabel wrote:
>>>>> Did Srini's explanations convinced you?
>>>>>
>>>>> If so, could you queue the series for v3.15?
>>> to be honest, I'm not comfortable with this explanation. If the
>>> "powerdown" bits only gate the clocks to those modules, calling it a
>>> reset control is clearly the wrong abstraction. If that is the case,
>>> couldn't you handle those bits via the clock framework?
>> I just had a re-look at the IPs specs for more information on where
>> these power-down signals are actually terminating on the IP side.
>>
>> For example: ST-Synopsis Ethernet GMAC IP has two pins
>> power_down_req[IN] and power_down_ack[OUT]. power_down_req is used by
>> the software to either put the IP in powerdown or bring it out of
>> powerdown state.
>
> Now I'm a bit confused. There is no mention of GMAC in your patches,
> and for ETH[01] they contain only the SOFTRESET bits. I have no issue
> with the SOFTRESETs.
Yes, GMAC was a bad example indeed. However this same logic applies to
the USB IP as well.
GMAC power-down-reset can be added to the power-down-reset list for
consistency.
We did not define the power-down-reset for GMAC because the reset state
of GMAC will not be in power down. softreset should be enough to bring
the IP in to a usable state. So the software never drives the power
down-request but instead uses softreset in this particular case.
>
>> The IP itself drives power_down_ack to indicate when the power down
>> request is successfully finished. For power_down/power_up request the IP
>> will change the internal state accordingly including powering up/down
>> its internal blocks and/or clock gating.
>>
>>> If on the other hand these powerdown bits also trigger reset machinery,
>>> such that asserting and deasserting that bit will change the module's
>>> internal state, I could be convinced to queue them like this.
>> This is true with ST IPs, these lines change the state of the IP as
>> described above. Reset framework seems to fits in very well with this
>> behavior rather than power-domains or clock framework.
>
> If you put the IP in power down when it is idle, and then power it up
> again, will the IP registers have kept their previous state?
No, the context is lost, the IP needs re-initialization.
Thanks,
srini
>
> regards
> Philipp
>
>
>
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v2 0/6] ARM: STi reset controller support
@ 2014-02-25 9:47 ` Philipp Zabel
0 siblings, 0 replies; 72+ messages in thread
From: Philipp Zabel @ 2014-02-25 9:47 UTC (permalink / raw)
To: srinivas kandagatla
Cc: Maxime Coquelin, Mark Rutland, devicetree, Russell King, kernel,
Pawel Moll, Ian Campbell, Olof Johansson, linux-doc,
linux-kernel, stephen.gallimore, Rob Herring, Arnd Bergmann,
Rob Landley, Kumar Gala, Grant Likely, linux-arm-kernel
Hi Srinivas,
Am Dienstag, den 25.02.2014, 09:08 +0000 schrieb srinivas kandagatla:
> On 24/02/14 15:16, Philipp Zabel wrote:
> > Hi Srinivas,
> >
> > Am Montag, den 24.02.2014, 14:03 +0000 schrieb srinivas kandagatla:
> >> Thanks Philipp for your comments,
> >>
> >> On 24/02/14 10:33, Philipp Zabel wrote:
> >>>>> Did Srini's explanations convinced you?
> >>>>>
> >>>>> If so, could you queue the series for v3.15?
> >>> to be honest, I'm not comfortable with this explanation. If the
> >>> "powerdown" bits only gate the clocks to those modules, calling it a
> >>> reset control is clearly the wrong abstraction. If that is the case,
> >>> couldn't you handle those bits via the clock framework?
> >> I just had a re-look at the IPs specs for more information on where
> >> these power-down signals are actually terminating on the IP side.
> >>
> >> For example: ST-Synopsis Ethernet GMAC IP has two pins
> >> power_down_req[IN] and power_down_ack[OUT]. power_down_req is used by
> >> the software to either put the IP in powerdown or bring it out of
> >> powerdown state.
> >
> > Now I'm a bit confused. There is no mention of GMAC in your patches,
> > and for ETH[01] they contain only the SOFTRESET bits. I have no issue
> > with the SOFTRESETs.
> Yes, GMAC was a bad example indeed. However this same logic applies to
> the USB IP as well.
>
> GMAC power-down-reset can be added to the power-down-reset list for
> consistency.
>
> We did not define the power-down-reset for GMAC because the reset state
> of GMAC will not be in power down. softreset should be enough to bring
> the IP in to a usable state. So the software never drives the power
> down-request but instead uses softreset in this particular case.
>
> >
> >> The IP itself drives power_down_ack to indicate when the power down
> >> request is successfully finished. For power_down/power_up request the IP
> >> will change the internal state accordingly including powering up/down
> >> its internal blocks and/or clock gating.
> >>
> >>> If on the other hand these powerdown bits also trigger reset machinery,
> >>> such that asserting and deasserting that bit will change the module's
> >>> internal state, I could be convinced to queue them like this.
> >> This is true with ST IPs, these lines change the state of the IP as
> >> described above. Reset framework seems to fits in very well with this
> >> behavior rather than power-domains or clock framework.
> >
> > If you put the IP in power down when it is idle, and then power it up
> > again, will the IP registers have kept their previous state?
> No, the context is lost, the IP needs re-initialization.
alright then, I'll add them to the queue.
thanks
Philipp
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 0/6] ARM: STi reset controller support
@ 2014-02-25 9:47 ` Philipp Zabel
0 siblings, 0 replies; 72+ messages in thread
From: Philipp Zabel @ 2014-02-25 9:47 UTC (permalink / raw)
To: linux-arm-kernel
Hi Srinivas,
Am Dienstag, den 25.02.2014, 09:08 +0000 schrieb srinivas kandagatla:
> On 24/02/14 15:16, Philipp Zabel wrote:
> > Hi Srinivas,
> >
> > Am Montag, den 24.02.2014, 14:03 +0000 schrieb srinivas kandagatla:
> >> Thanks Philipp for your comments,
> >>
> >> On 24/02/14 10:33, Philipp Zabel wrote:
> >>>>> Did Srini's explanations convinced you?
> >>>>>
> >>>>> If so, could you queue the series for v3.15?
> >>> to be honest, I'm not comfortable with this explanation. If the
> >>> "powerdown" bits only gate the clocks to those modules, calling it a
> >>> reset control is clearly the wrong abstraction. If that is the case,
> >>> couldn't you handle those bits via the clock framework?
> >> I just had a re-look at the IPs specs for more information on where
> >> these power-down signals are actually terminating on the IP side.
> >>
> >> For example: ST-Synopsis Ethernet GMAC IP has two pins
> >> power_down_req[IN] and power_down_ack[OUT]. power_down_req is used by
> >> the software to either put the IP in powerdown or bring it out of
> >> powerdown state.
> >
> > Now I'm a bit confused. There is no mention of GMAC in your patches,
> > and for ETH[01] they contain only the SOFTRESET bits. I have no issue
> > with the SOFTRESETs.
> Yes, GMAC was a bad example indeed. However this same logic applies to
> the USB IP as well.
>
> GMAC power-down-reset can be added to the power-down-reset list for
> consistency.
>
> We did not define the power-down-reset for GMAC because the reset state
> of GMAC will not be in power down. softreset should be enough to bring
> the IP in to a usable state. So the software never drives the power
> down-request but instead uses softreset in this particular case.
>
> >
> >> The IP itself drives power_down_ack to indicate when the power down
> >> request is successfully finished. For power_down/power_up request the IP
> >> will change the internal state accordingly including powering up/down
> >> its internal blocks and/or clock gating.
> >>
> >>> If on the other hand these powerdown bits also trigger reset machinery,
> >>> such that asserting and deasserting that bit will change the module's
> >>> internal state, I could be convinced to queue them like this.
> >> This is true with ST IPs, these lines change the state of the IP as
> >> described above. Reset framework seems to fits in very well with this
> >> behavior rather than power-domains or clock framework.
> >
> > If you put the IP in power down when it is idle, and then power it up
> > again, will the IP registers have kept their previous state?
> No, the context is lost, the IP needs re-initialization.
alright then, I'll add them to the queue.
thanks
Philipp
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v2 0/6] ARM: STi reset controller support
@ 2014-02-25 9:47 ` Philipp Zabel
0 siblings, 0 replies; 72+ messages in thread
From: Philipp Zabel @ 2014-02-25 9:47 UTC (permalink / raw)
To: srinivas kandagatla
Cc: Maxime Coquelin, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
Russell King, kernel-F5mvAk5X5gdBDgjK7y7TUQ, Pawel Moll,
Ian Campbell, Olof Johansson, linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
stephen.gallimore-qxv4g6HH51o, Rob Herring, Arnd Bergmann,
Rob Landley, Kumar Gala, Grant Likely,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Hi Srinivas,
Am Dienstag, den 25.02.2014, 09:08 +0000 schrieb srinivas kandagatla:
> On 24/02/14 15:16, Philipp Zabel wrote:
> > Hi Srinivas,
> >
> > Am Montag, den 24.02.2014, 14:03 +0000 schrieb srinivas kandagatla:
> >> Thanks Philipp for your comments,
> >>
> >> On 24/02/14 10:33, Philipp Zabel wrote:
> >>>>> Did Srini's explanations convinced you?
> >>>>>
> >>>>> If so, could you queue the series for v3.15?
> >>> to be honest, I'm not comfortable with this explanation. If the
> >>> "powerdown" bits only gate the clocks to those modules, calling it a
> >>> reset control is clearly the wrong abstraction. If that is the case,
> >>> couldn't you handle those bits via the clock framework?
> >> I just had a re-look at the IPs specs for more information on where
> >> these power-down signals are actually terminating on the IP side.
> >>
> >> For example: ST-Synopsis Ethernet GMAC IP has two pins
> >> power_down_req[IN] and power_down_ack[OUT]. power_down_req is used by
> >> the software to either put the IP in powerdown or bring it out of
> >> powerdown state.
> >
> > Now I'm a bit confused. There is no mention of GMAC in your patches,
> > and for ETH[01] they contain only the SOFTRESET bits. I have no issue
> > with the SOFTRESETs.
> Yes, GMAC was a bad example indeed. However this same logic applies to
> the USB IP as well.
>
> GMAC power-down-reset can be added to the power-down-reset list for
> consistency.
>
> We did not define the power-down-reset for GMAC because the reset state
> of GMAC will not be in power down. softreset should be enough to bring
> the IP in to a usable state. So the software never drives the power
> down-request but instead uses softreset in this particular case.
>
> >
> >> The IP itself drives power_down_ack to indicate when the power down
> >> request is successfully finished. For power_down/power_up request the IP
> >> will change the internal state accordingly including powering up/down
> >> its internal blocks and/or clock gating.
> >>
> >>> If on the other hand these powerdown bits also trigger reset machinery,
> >>> such that asserting and deasserting that bit will change the module's
> >>> internal state, I could be convinced to queue them like this.
> >> This is true with ST IPs, these lines change the state of the IP as
> >> described above. Reset framework seems to fits in very well with this
> >> behavior rather than power-domains or clock framework.
> >
> > If you put the IP in power down when it is idle, and then power it up
> > again, will the IP registers have kept their previous state?
> No, the context is lost, the IP needs re-initialization.
alright then, I'll add them to the queue.
thanks
Philipp
--
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] 72+ messages in thread
* Re: [PATCH v2 0/6] ARM: STi reset controller support
2014-02-25 9:47 ` Philipp Zabel
(?)
@ 2014-02-25 10:56 ` srinivas kandagatla
-1 siblings, 0 replies; 72+ messages in thread
From: srinivas kandagatla @ 2014-02-25 10:56 UTC (permalink / raw)
To: Philipp Zabel, Olof Johansson, Arnd Bergmann
Cc: Maxime Coquelin, Mark Rutland, devicetree, Russell King, kernel,
Pawel Moll, Ian Campbell, linux-doc, linux-kernel,
stephen.gallimore, Rob Herring, Rob Landley, Kumar Gala,
Grant Likely, linux-arm-kernel
Thankyou Philipp,
On 25/02/14 09:47, Philipp Zabel wrote:
>> No, the context is lost, the IP needs re-initialization.
> alright then, I'll add them to the queue.
Thats Great..
Can I ask your Ack on these patches so that I can request Arnd/Olof to
take these patches via arm-soc tree.
Hi Arnd/Olof,
I have few more DT patches which depend on the reset controller header
file. Is is possible to take the reset controller patches with Philipp's
Acks via arm-soc tree?
Thanks,
srini
>
> thanks
> Philipp
>
>
>
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 0/6] ARM: STi reset controller support
@ 2014-02-25 10:56 ` srinivas kandagatla
0 siblings, 0 replies; 72+ messages in thread
From: srinivas kandagatla @ 2014-02-25 10:56 UTC (permalink / raw)
To: linux-arm-kernel
Thankyou Philipp,
On 25/02/14 09:47, Philipp Zabel wrote:
>> No, the context is lost, the IP needs re-initialization.
> alright then, I'll add them to the queue.
Thats Great..
Can I ask your Ack on these patches so that I can request Arnd/Olof to
take these patches via arm-soc tree.
Hi Arnd/Olof,
I have few more DT patches which depend on the reset controller header
file. Is is possible to take the reset controller patches with Philipp's
Acks via arm-soc tree?
Thanks,
srini
>
> thanks
> Philipp
>
>
>
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v2 0/6] ARM: STi reset controller support
@ 2014-02-25 10:56 ` srinivas kandagatla
0 siblings, 0 replies; 72+ messages in thread
From: srinivas kandagatla @ 2014-02-25 10:56 UTC (permalink / raw)
To: Philipp Zabel, Olof Johansson, Arnd Bergmann
Cc: Maxime Coquelin, Mark Rutland, devicetree, Russell King, kernel,
Pawel Moll, Ian Campbell, linux-doc, linux-kernel,
stephen.gallimore, Rob Herring, Rob Landley, Kumar Gala,
Grant Likely, linux-arm-kernel
Thankyou Philipp,
On 25/02/14 09:47, Philipp Zabel wrote:
>> No, the context is lost, the IP needs re-initialization.
> alright then, I'll add them to the queue.
Thats Great..
Can I ask your Ack on these patches so that I can request Arnd/Olof to
take these patches via arm-soc tree.
Hi Arnd/Olof,
I have few more DT patches which depend on the reset controller header
file. Is is possible to take the reset controller patches with Philipp's
Acks via arm-soc tree?
Thanks,
srini
>
> thanks
> Philipp
>
>
>
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v2 0/6] ARM: STi reset controller support
@ 2014-02-25 11:15 ` Philipp Zabel
0 siblings, 0 replies; 72+ messages in thread
From: Philipp Zabel @ 2014-02-25 11:15 UTC (permalink / raw)
To: srinivas kandagatla
Cc: Olof Johansson, Arnd Bergmann, Maxime Coquelin, Mark Rutland,
devicetree, Russell King, kernel, Pawel Moll, Ian Campbell,
linux-doc, linux-kernel, stephen.gallimore, Rob Herring,
Rob Landley, Kumar Gala, Grant Likely, linux-arm-kernel
Hi Srinivas,
Am Dienstag, den 25.02.2014, 10:56 +0000 schrieb srinivas kandagatla:
> Thankyou Philipp,
> On 25/02/14 09:47, Philipp Zabel wrote:
> >> No, the context is lost, the IP needs re-initialization.
> > alright then, I'll add them to the queue.
> Thats Great..
> Can I ask your Ack on these patches so that I can request Arnd/Olof to
> take these patches via arm-soc tree.
>
> Hi Arnd/Olof,
>
> I have few more DT patches which depend on the reset controller header
> file. Is is possible to take the reset controller patches with Philipp's
> Acks via arm-soc tree?
That's fine with me, too. Shall I back the patches out of the reset
queue, then?
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
regards
Philipp
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 0/6] ARM: STi reset controller support
@ 2014-02-25 11:15 ` Philipp Zabel
0 siblings, 0 replies; 72+ messages in thread
From: Philipp Zabel @ 2014-02-25 11:15 UTC (permalink / raw)
To: linux-arm-kernel
Hi Srinivas,
Am Dienstag, den 25.02.2014, 10:56 +0000 schrieb srinivas kandagatla:
> Thankyou Philipp,
> On 25/02/14 09:47, Philipp Zabel wrote:
> >> No, the context is lost, the IP needs re-initialization.
> > alright then, I'll add them to the queue.
> Thats Great..
> Can I ask your Ack on these patches so that I can request Arnd/Olof to
> take these patches via arm-soc tree.
>
> Hi Arnd/Olof,
>
> I have few more DT patches which depend on the reset controller header
> file. Is is possible to take the reset controller patches with Philipp's
> Acks via arm-soc tree?
That's fine with me, too. Shall I back the patches out of the reset
queue, then?
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
regards
Philipp
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v2 0/6] ARM: STi reset controller support
@ 2014-02-25 11:15 ` Philipp Zabel
0 siblings, 0 replies; 72+ messages in thread
From: Philipp Zabel @ 2014-02-25 11:15 UTC (permalink / raw)
To: srinivas kandagatla
Cc: Olof Johansson, Arnd Bergmann, Maxime Coquelin, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King,
kernel-F5mvAk5X5gdBDgjK7y7TUQ, Pawel Moll, Ian Campbell,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
stephen.gallimore-qxv4g6HH51o, Rob Herring, Rob Landley,
Kumar Gala, Grant Likely,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Hi Srinivas,
Am Dienstag, den 25.02.2014, 10:56 +0000 schrieb srinivas kandagatla:
> Thankyou Philipp,
> On 25/02/14 09:47, Philipp Zabel wrote:
> >> No, the context is lost, the IP needs re-initialization.
> > alright then, I'll add them to the queue.
> Thats Great..
> Can I ask your Ack on these patches so that I can request Arnd/Olof to
> take these patches via arm-soc tree.
>
> Hi Arnd/Olof,
>
> I have few more DT patches which depend on the reset controller header
> file. Is is possible to take the reset controller patches with Philipp's
> Acks via arm-soc tree?
That's fine with me, too. Shall I back the patches out of the reset
queue, then?
Acked-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
regards
Philipp
--
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] 72+ messages in thread