Thread (21 messages) 21 messages, 2 authors, 2019-08-30

Re: [PATCHv2 05/11] soc: ti: omap-prm: sync func clock status with resets

From: Philipp Zabel <p.zabel@pengutronix.de>
Date: 2019-08-29 13:25:14
Also in: linux-devicetree, linux-omap

On Wed, 2019-08-28 at 10:19 +0300, Tero Kristo wrote:
quoted hunk ↗ jump to hunk
Hardware reset signals are tightly coupled with associated clocks, and
basically de-asserting a reset won't succeed properly if the clock is
not enabled, and vice-versa. Also, disabling a clock won't fully succeed
if the associated hardware resets are not asserted. Add status sync
functionality between these two for TI drivers so that the situations
can be handled properly without generating any timeouts.

Signed-off-by: Tero Kristo <redacted>
---
 drivers/soc/ti/omap_prm.c | 36 ++++++++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)
diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
index 38998ce19c71..e876bad8f8d5 100644
--- a/drivers/soc/ti/omap_prm.c
+++ b/drivers/soc/ti/omap_prm.c
@@ -15,6 +15,8 @@
 #include <linux/platform_device.h>
 #include <linux/reset-controller.h>
 #include <linux/delay.h>
+#include <linux/clk.h>
+#include <linux/clk/ti.h>
 
 #include <linux/platform_data/ti-prm.h>
 
@@ -42,7 +44,9 @@ struct omap_reset_data {
 	struct reset_controller_dev rcdev;
 	struct omap_prm *prm;
 	struct clockdomain *clkdm;
+	struct clk *clk;
 	struct device *dev;
+	u32 mask;
 };
 
 #define to_omap_reset_data(p) container_of((p), struct omap_reset_data, rcdev)
@@ -102,6 +106,8 @@ static int omap_reset_assert(struct reset_controller_dev *rcdev,
 	v |= 1 << id;
 	writel_relaxed(v, reset->prm->base + reset->prm->data->rstctrl);
 
+	ti_clk_notify_resets(reset->clk, v == reset->mask);
+
 	return 0;
 }
 
@@ -163,9 +169,19 @@ static int omap_reset_deassert(struct reset_controller_dev *rcdev,
 	v &= ~(1 << id);
 	writel_relaxed(v, reset->prm->base + reset->prm->data->rstctrl);
 
+	ti_clk_notify_resets(reset->clk, v == reset->mask);
+
 	if (!has_rstst)
 		goto exit;
 
+	/* If associated clock is disabled, we can't poll completion status */
+	if (reset->clk) {
+		struct clk_hw *hw = __clk_get_hw(reset->clk);
+
+		if (!clk_hw_is_enabled(hw))
+			return ret;
+	}
+
 	/* wait for the status to be set */
 	while (1) {
 		v = readl_relaxed(reset->prm->base + reset->prm->data->rstst);
@@ -199,8 +215,10 @@ static int omap_prm_reset_init(struct platform_device *pdev,
 			       struct omap_prm *prm)
 {
 	struct omap_reset_data *reset;
+	const struct omap_rst_map *map;
 	struct ti_prm_platform_data *pdata = dev_get_platdata(&pdev->dev);
 	char buf[32];
+	u32 v;
 
 	/*
 	 * Check if we have controllable resets. If either rstctrl is non-zero
@@ -215,6 +233,10 @@ static int omap_prm_reset_init(struct platform_device *pdev,
 	    !pdata->clkdm_allow_idle)
 		return -EINVAL;
 
+	map = prm->data->rstmap;
+	if (!map)
+		return -EINVAL;
Can this actually happen?
quoted hunk ↗ jump to hunk
+
 	reset = devm_kzalloc(&pdev->dev, sizeof(*reset), GFP_KERNEL);
 	if (!reset)
 		return -ENOMEM;
@@ -224,6 +246,10 @@ static int omap_prm_reset_init(struct platform_device *pdev,
 	reset->rcdev.of_node = pdev->dev.of_node;
 	reset->rcdev.nr_resets = OMAP_MAX_RESETS;
 	reset->dev = &pdev->dev;
+	reset->clk = of_clk_get(pdev->dev.of_node, 0);
+
+	if (IS_ERR(reset->clk))
+		reset->clk = NULL;
Maybe only ignore -ENOENT?
quoted hunk ↗ jump to hunk
 	reset->prm = prm;
 
@@ -234,6 +260,16 @@ static int omap_prm_reset_init(struct platform_device *pdev,
 	if (!reset->clkdm)
 		return -EINVAL;
 
+	while (map->rst >= 0) {
+		reset->mask |= BIT(map->rst);
+		map++;
+	}
With this, you could use reset->mask to simplify _is_valid_reset.

regards
Philipp

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help