ARM: davinci: complete the conversion to using the reset framework

From: Bartosz Golaszewski <[email protected]>

Commit 7af1bb19f1d7 ("reset: add support for non-DT systems") introduced reset control lookup mechanism for boards that still use board files.

The routine used to register lookup entries takes the corresponding reset_controlled_dev structure as argument.

It's been determined however that for the first user of this new interface - davinci psc driver - it will be easier to register the lookup entries using the reset controller device name.

This patch changes the way lookup entries are added.

Signed-off-by Bartosz Golaszewski <[email protected]>

---
 drivers/reset/core.c             | 38 +++++++++++++++++++++++++++++++-------
 include/linux/reset-controller.h | 14 ++++++++------
 2 files changed, 39 insertions(+), 13 deletions(-)

drivers/reset/core.c +22 -6

index 06fa4907afc4..f4a29c046995 100644
@@ -153,12 +153,10 @@ EXPORT_SYMBOL_GPL(devm_reset_controller_register);
 
 /**
  * reset_controller_add_lookup - register a set of lookup entries
- * @rcdev: initialized reset controller device owning the reset line
  * @lookup: array of reset lookup entries
  * @num_entries: number of entries in the lookup array
  */
-void reset_controller_add_lookup(struct reset_controller_dev *rcdev,
-				 struct reset_control_lookup *lookup,
+void reset_controller_add_lookup(struct reset_control_lookup *lookup,
 				 unsigned int num_entries)
 {
 	struct reset_control_lookup *entry;

@@ -168,13 +166,12 @@ void reset_controller_add_lookup(struct reset_controller_dev *rcdev,
 	for (i = 0; i < num_entries; i++) {
 		entry = &lookup[i];
 
-		if (!entry->dev_id) {
-			pr_warn("%s(): reset lookup entry has no dev_id, skipping\n",
+		if (!entry->dev_id || !entry->provider) {
+			pr_warn("%s(): reset lookup entry badly specified, skipping\n",
 				__func__);
 			continue;
 		}
 
-		entry->rcdev = rcdev;
 		list_add_tail(&entry->list, &reset_lookup_list);
 	}
 	mutex_unlock(&reset_lookup_mutex);

@@ -526,11 +523,30 @@ struct reset_control *__of_reset_control_get(struct device_node *node,
 }
 EXPORT_SYMBOL_GPL(__of_reset_control_get);
 
+static struct reset_controller_dev *
+__reset_controller_by_name(const char *name)
+{
+	struct reset_controller_dev *rcdev;
+
+	lockdep_assert_held(&reset_list_mutex);
+
+	list_for_each_entry(rcdev, &reset_controller_list, list) {
+		if (!rcdev->dev)
+			continue;
+
+		if (!strcmp(name, dev_name(rcdev->dev)))
+			return rcdev;
+	}
+
+	return NULL;
+}
+
 static struct reset_control *
 __reset_control_get_from_lookup(struct device *dev, const char *con_id,
 				bool shared, bool optional)
 {
 	const struct reset_control_lookup *lookup;
+	struct reset_controller_dev *rcdev;
 	const char *dev_id = dev_name(dev);
 	struct reset_control *rstc = NULL;
 

Quoted 87 lines

From: Bartosz Golaszewski <[email protected]>

Commit 7af1bb19f1d7 ("reset: add support for non-DT systems") introduced reset control lookup mechanism for boards that still use board files.

The routine used to register lookup entries takes the corresponding reset_controlled_dev structure as argument.

It's been determined however that for the first user of this new interface - davinci psc driver - it will be easier to register the lookup entries using the reset controller device name.

This patch changes the way lookup entries are added.

Signed-off-by Bartosz Golaszewski <[email protected]>

---
 drivers/reset/core.c             | 38 +++++++++++++++++++++++++++++++-------
 include/linux/reset-controller.h | 14 ++++++++------
 2 files changed, 39 insertions(+), 13 deletions(-)

drivers/reset/core.c +22 -6

index 06fa4907afc4..f4a29c046995 100644
@@ -153,12 +153,10 @@ EXPORT_SYMBOL_GPL(devm_reset_controller_register);
 
 /**
  * reset_controller_add_lookup - register a set of lookup entries
- * @rcdev: initialized reset controller device owning the reset line
  * @lookup: array of reset lookup entries
  * @num_entries: number of entries in the lookup array
  */
-void reset_controller_add_lookup(struct reset_controller_dev *rcdev,
-                              struct reset_control_lookup *lookup,
+void reset_controller_add_lookup(struct reset_control_lookup *lookup,
                               unsigned int num_entries)
 {
      struct reset_control_lookup *entry;

@@ -168,13 +166,12 @@ void reset_controller_add_lookup(struct reset_controller_dev *rcdev,
      for (i = 0; i < num_entries; i++) {
              entry = &lookup[i];
 
-             if (!entry->dev_id) {
-                     pr_warn("%s(): reset lookup entry has no dev_id, skipping\n",
+             if (!entry->dev_id || !entry->provider) {
+                     pr_warn("%s(): reset lookup entry badly specified, skipping\n",
                              __func__);
                      continue;
              }
 
-             entry->rcdev = rcdev;
              list_add_tail(&entry->list, &reset_lookup_list);
      }
      mutex_unlock(&reset_lookup_mutex);

@@ -526,11 +523,30 @@ struct reset_control *__of_reset_control_get(struct device_node *node,
 }
 EXPORT_SYMBOL_GPL(__of_reset_control_get);
 
+static struct reset_controller_dev *
+__reset_controller_by_name(const char *name)
+{
+     struct reset_controller_dev *rcdev;
+
+     lockdep_assert_held(&reset_list_mutex);
+
+     list_for_each_entry(rcdev, &reset_controller_list, list) {
+             if (!rcdev->dev)
+                     continue;
+
+             if (!strcmp(name, dev_name(rcdev->dev)))
+                     return rcdev;
+     }
+
+     return NULL;
+}
+
 static struct reset_control *
 __reset_control_get_from_lookup(struct device *dev, const char *con_id,
                              bool shared, bool optional)
 {
      const struct reset_control_lookup *lookup;
+     struct reset_controller_dev *rcdev;
      const char *dev_id = dev_name(dev);
      struct reset_control *rstc = NULL;
 

drivers/reset/core.c __reset_control_get_from_lookup(struct device *dev, const char *con_id, · line 571

Quoted 10 lines

drivers/reset/core.c +6 -1

@@ -547,7 +563,15 @@ __reset_control_get_from_lookup(struct device *dev, const char *con_id,
                  ((con_id && lookup->con_id) &&
                   !strcmp(con_id, lookup->con_id))) {
                      mutex_lock(&reset_list_mutex);
-                     rstc = __reset_control_get_internal(lookup->rcdev,
+                     rcdev = __reset_controller_by_name(lookup->provider);
+                     if (!rcdev) {
+                             mutex_unlock(&reset_list_mutex);
+                             mutex_unlock(&reset_lookup_mutex);
+                             /* Reset provider may not be ready yet. */
+                             return -EPROBE_DEFER;

Thanks, I've applied this patch to reset/next with the following change:

(quoted diff) +1 -1

-                               return -EPROBE_DEFER;
+                               return ERR_PTR(-EPROBE_DEFER);

regards
Philipp

From: Bartosz Golaszewski <[email protected]>

The davinci platform is being switched to using the common clock framework, where clk_enable() can fail. Add the return value check.

Signed-off-by Bartosz Golaszewski <[email protected]>

---
 drivers/remoteproc/da8xx_remoteproc.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

drivers/remoteproc/da8xx_remoteproc.c +7 -1

index bf3b9034c319..2b24291337b7 100644
@@ -138,6 +138,7 @@ static int da8xx_rproc_start(struct rproc *rproc)
 	struct device *dev = rproc->dev.parent;
 	struct da8xx_rproc *drproc = (struct da8xx_rproc *)rproc->priv;
 	struct clk *dsp_clk = drproc->dsp_clk;
+	int ret;
 
 	/* hw requires the start (boot) address be on 1KB boundary */
 	if (rproc->bootaddr & 0x3ff) {

@@ -148,7 +149,12 @@ static int da8xx_rproc_start(struct rproc *rproc)
 
 	writel(rproc->bootaddr, drproc->bootreg);
 
-	clk_enable(dsp_clk);
+	ret = clk_enable(dsp_clk);
+	if (ret) {
+		dev_err(dev, "clk_enable() failed: %d\n", ret);
+		return ret;
+	}
+
 	davinci_clk_reset_deassert(dsp_clk);
 
 	return 0;

From: Bartosz Golaszewski <[email protected]>

We're currently switching the platform to using the common clock framework. We need to explicitly prepare and unprepare the rproc clock.

Signed-off-by Bartosz Golaszewski <[email protected]>

---
 drivers/remoteproc/da8xx_remoteproc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

drivers/remoteproc/da8xx_remoteproc.c +3 -3

index 2b24291337b7..f134192922e0 100644
@@ -149,9 +149,9 @@ static int da8xx_rproc_start(struct rproc *rproc)
 
 	writel(rproc->bootaddr, drproc->bootreg);
 
-	ret = clk_enable(dsp_clk);
+	ret = clk_prepare_enable(dsp_clk);
 	if (ret) {
-		dev_err(dev, "clk_enable() failed: %d\n", ret);
+		dev_err(dev, "clk_prepare_enable() failed: %d\n", ret);
 		return ret;
 	}
 

@@ -165,7 +165,7 @@ static int da8xx_rproc_stop(struct rproc *rproc)
 	struct da8xx_rproc *drproc = rproc->priv;
 
 	davinci_clk_reset_assert(drproc->dsp_clk);
-	clk_disable(drproc->dsp_clk);
+	clk_disable_unprepare(drproc->dsp_clk);
 
 	return 0;
 }

From: Bartosz Golaszewski <[email protected]>

Switch to using the reset framework instead of handcoded reset routines we used so far.

Signed-off-by Bartosz Golaszewski <[email protected]>

---
 drivers/remoteproc/da8xx_remoteproc.c | 32 +++++++++++++++++++++++++++-----
 1 file changed, 27 insertions(+), 5 deletions(-)

drivers/remoteproc/da8xx_remoteproc.c +3 -2

index f134192922e0..3689473f8b49 100644
@@ -10,6 +10,7 @@
 
 #include <linux/bitops.h>
 #include <linux/clk.h>
+#include <linux/reset.h>
 #include <linux/err.h>
 #include <linux/interrupt.h>
 #include <linux/io.h>

@@ -20,8 +21,6 @@
 #include <linux/platform_device.h>
 #include <linux/remoteproc.h>
 
-#include <mach/clock.h>   /* for davinci_clk_reset_assert/deassert() */
-
 #include "remoteproc_internal.h"
 
 static char *da8xx_fw_name;

@@ -72,6 +71,7 @@ struct da8xx_rproc {
 	struct da8xx_rproc_mem *mem;
 	int num_mems;
 	struct clk *dsp_clk;
+	struct reset_control *dsp_reset;
 	void (*ack_fxn)(struct irq_data *data);
 	struct irq_data *irq_data;
 	void __iomem *chipsig;

@@ -138,6 +138,7 @@ static int da8xx_rproc_start(struct rproc *rproc)
 	struct device *dev = rproc->dev.parent;
 	struct da8xx_rproc *drproc = (struct da8xx_rproc *)rproc->priv;
 	struct clk *dsp_clk = drproc->dsp_clk;
+	struct reset_control *dsp_reset = drproc->dsp_reset;
 	int ret;
 
 	/* hw requires the start (boot) address be on 1KB boundary */

drivers/remoteproc/da8xx_remoteproc.c +1 -0

+	}
 
 	return 0;
 }

drivers/remoteproc/da8xx_remoteproc.c +12 -1

+		return ret;
+	}
 
-	davinci_clk_reset_assert(drproc->dsp_clk);
 	clk_disable_unprepare(drproc->dsp_clk);
 
 	return 0;

@@ -232,6 +244,7 @@ static int da8xx_rproc_probe(struct platform_device *pdev)
 	struct resource *bootreg_res;
 	struct resource *chipsig_res;
 	struct clk *dsp_clk;
+	struct reset_control *dsp_reset;
 	void __iomem *chipsig;
 	void __iomem *bootreg;
 	int irq;

@@ -268,6 +281,15 @@ static int da8xx_rproc_probe(struct platform_device *pdev)
 		return PTR_ERR(dsp_clk);
 	}
 
+	dsp_reset = devm_reset_control_get_exclusive(dev, NULL);
+	if (IS_ERR(dsp_reset)) {
+		if (PTR_ERR(dsp_reset) != -EPROBE_DEFER)
+			dev_err(dev, "unable to get reset control: %ld\n",
+				PTR_ERR(dsp_reset));
+
+		return PTR_ERR(dsp_reset);
+	}
+
 	if (dev->of_node) {
 		ret = of_reserved_mem_device_init(dev);
 		if (ret) {

From: Bartosz Golaszewski <[email protected]>

This series converts the only user of the handcoded, mach-specific reset routines in the davinci platform to using the reset framework.

Patch 1 modifies the way lookup entries are registered with the reset framework.

Patches 2-4 add necessary lookups/DT-properties.

Patches 5-7 convert the davinci-rproc driver to the reset framework.

Patch 8 removes now dead code.

Philipp: it turned out that it's indeed better to use the reset controller's device name for the entry lookup.

Tested both in DT and legacy modes by booting the examples from ti-ipc-rtos recipe in meta-ti.

This series applies on top of David Lechner's common-clk-v9 branch[1] with Philipp Zabel's reset/next branch[2] pulled in.

It can be found in my github tree as well[3].

Quoting Bartosz Golaszewski (2018-03-23 06:04:47)

Quoted 20 lines

From: Bartosz Golaszewski <[email protected]>

This series converts the only user of the handcoded, mach-specific reset routines in the davinci platform to using the reset framework.

Patch 1 modifies the way lookup entries are registered with the reset framework.

Patches 2-4 add necessary lookups/DT-properties.

Patches 5-7 convert the davinci-rproc driver to the reset framework.

Patch 8 removes now dead code.

Philipp: it turned out that it's indeed better to use the reset controller's device name for the entry lookup.

Tested both in DT and legacy modes by booting the examples from ti-ipc-rtos recipe in meta-ti.

Quoted 5 lines

This series applies on top of David Lechner's common-clk-v9 branch[1] with Philipp Zabel's reset/next branch[2] pulled in.

It can be found in my github tree as well[3].

What's the merge strategy for the rest of the patches? I should apply the clk ones after the next -rc1?

2018-03-23 17:49 GMT+01:00 Stephen Boyd <[email protected]>:

Quoted 27 lines

Quoting Bartosz Golaszewski (2018-03-23 06:04:47)

Quoted 25 lines

From: Bartosz Golaszewski <[email protected]>

This series converts the only user of the handcoded, mach-specific reset routines in the davinci platform to using the reset framework.

Patch 1 modifies the way lookup entries are registered with the reset framework.

Patches 2-4 add necessary lookups/DT-properties.

Patches 5-7 convert the davinci-rproc driver to the reset framework.

Patch 8 removes now dead code.

Philipp: it turned out that it's indeed better to use the reset controller's device name for the entry lookup.

Tested both in DT and legacy modes by booting the examples from ti-ipc-rtos recipe in meta-ti.

This series applies on top of David Lechner's common-clk-v9 branch[1] with Philipp Zabel's reset/next branch[2] pulled in.

It can be found in my github tree as well[3].

Quoted 2 lines

What's the merge strategy for the rest of the patches? I should apply the clk ones after the next -rc1?

Or maybe Philipp can provide us with an immutable branch with the reset patches?

The you could apply the driver patches and let Sekhar take all the platform code?

Quoting Bartosz Golaszewski (2018-03-23 09:55:47)

Quoted 31 lines

2018-03-23 17:49 GMT+01:00 Stephen Boyd <[email protected]>:

Quoted 29 lines

Quoting Bartosz Golaszewski (2018-03-23 06:04:47)

Quoted 17 lines

From: Bartosz Golaszewski <[email protected]>

This series converts the only user of the handcoded, mach-specific reset routines in the davinci platform to using the reset framework.

Patch 1 modifies the way lookup entries are registered with the reset framework.

Patches 2-4 add necessary lookups/DT-properties.

Patches 5-7 convert the davinci-rproc driver to the reset framework.

Patch 8 removes now dead code.

Philipp: it turned out that it's indeed better to use the reset controller's device name for the entry lookup.

Quoted 8 lines

Tested both in DT and legacy modes by booting the examples from ti-ipc-rtos recipe in meta-ti.

This series applies on top of David Lechner's common-clk-v9 branch[1] with Philipp Zabel's reset/next branch[2] pulled in.

It can be found in my github tree as well[3].

What's the merge strategy for the rest of the patches? I should apply the clk ones after the next -rc1?

Quoted 5 lines

Or maybe Philipp can provide us with an immutable branch with the reset patches?

The you could apply the driver patches and let Sekhar take all the platform code?

Ok that could work too.

2018-03-23 18:08 GMT+01:00 Stephen Boyd <[email protected]>:

Quoted 38 lines

Quoting Bartosz Golaszewski (2018-03-23 09:55:47)

Quoted 36 lines

2018-03-23 17:49 GMT+01:00 Stephen Boyd <[email protected]>:

Quoted 21 lines

Quoting Bartosz Golaszewski (2018-03-23 06:04:47)

Quoted 20 lines

From: Bartosz Golaszewski <[email protected]>

This series converts the only user of the handcoded, mach-specific reset routines in the davinci platform to using the reset framework.

Patch 1 modifies the way lookup entries are registered with the reset framework.

Patches 2-4 add necessary lookups/DT-properties.

Patches 5-7 convert the davinci-rproc driver to the reset framework.

Patch 8 removes now dead code.

Philipp: it turned out that it's indeed better to use the reset controller's device name for the entry lookup.

Tested both in DT and legacy modes by booting the examples from ti-ipc-rtos recipe in meta-ti.

Quoted 8 lines

Quoted 5 lines

This series applies on top of David Lechner's common-clk-v9 branch[1] with Philipp Zabel's reset/next branch[2] pulled in.

It can be found in my github tree as well[3].

What's the merge strategy for the rest of the patches? I should apply the clk ones after the next -rc1?

Or maybe Philipp can provide us with an immutable branch with the reset patches?

The you could apply the driver patches and let Sekhar take all the platform code?

Quoted 1 line

Ok that could work too.

Ohad, Bjorn can you ack the remoteproc patches? Are you OK with Stephen taking them through the clock tree? Otherwise it would get complicated since they depend on the first clk patch and the last clk patch depends on them.

Thanks,
Bart
--
To unsubscribe from this list: send the line "unsubscribe linux-remoteproc" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Hi Bart,

Quoted 39 lines · Bartosz Golaszewski

2018-03-23 18:08 GMT+01:00 Stephen Boyd <[email protected]>:

Quoted 38 lines

Quoting Bartosz Golaszewski (2018-03-23 09:55:47)

Quoted 36 lines

2018-03-23 17:49 GMT+01:00 Stephen Boyd <[email protected]>:

Quoted 21 lines

Quoting Bartosz Golaszewski (2018-03-23 06:04:47)

Quoted 20 lines

From: Bartosz Golaszewski <[email protected]>

This series converts the only user of the handcoded, mach-specific reset routines in the davinci platform to using the reset framework.

Patch 1 modifies the way lookup entries are registered with the reset framework.

Patches 2-4 add necessary lookups/DT-properties.

Patches 5-7 convert the davinci-rproc driver to the reset framework.

Patch 8 removes now dead code.

Philipp: it turned out that it's indeed better to use the reset controller's device name for the entry lookup.

Tested both in DT and legacy modes by booting the examples from ti-ipc-rtos recipe in meta-ti.

Quoted 8 lines

Quoted 5 lines

This series applies on top of David Lechner's common-clk-v9 branch[1] with Philipp Zabel's reset/next branch[2] pulled in.

It can be found in my github tree as well[3].

What's the merge strategy for the rest of the patches? I should apply the clk ones after the next -rc1?

Or maybe Philipp can provide us with an immutable branch with the reset patches?

The you could apply the driver patches and let Sekhar take all the platform code?

Quoted 6 lines

Quoted 1 line

Ok that could work too.

Ohad, Bjorn can you ack the remoteproc patches? Are you OK with Stephen taking them through the clock tree? Otherwise it would get complicated since they depend on the first clk patch and the last clk patch depends on them.

I will take a closer look and test on Mon. A quick glance of the remoteproc changes seem to be fine. I will let Bjorn comment on the patch flow.

The only reason I had to use the clock in the driver was for the reset before, and hopefully this will allow me to actually switch to using pm_runtime API like I do with the rest of the TI remoteproc drivers (Keystone remoteproc driver also uses PSC for clock and reset but then it goes through different set of drivers).

So, I see a mix of driver and dts patches in the series, are all the dts patches coming through Sekhar?

regards
Suman

Quoted 8 lines

Thanks,
Bart
--
To unsubscribe from this list: send the line "unsubscribe linux-remoteproc" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-remoteproc" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

I tried booting your tree [3] on the OMAPL138-LCDK board. I am using NFS, and I am unable to get to the console. I don't have any issues booting latest -next branch (next-20180326) which only has the reset and clock driver related changes.

Here's the log towards the end of the boot..
---
pinctrl-single 1c14120.pinmux: 160 pins, size 80
Serial: 8250/16550 driver, 3 ports, IRQ sharing disabled console [ttyS2] disabled
1d0d000.serial: ttyS2 at MMIO 0x1d0d000 (irq = 61, base_baud = 8250000) is a TI DA8xx/66AK2x
console [ttyS2] enabled
brd: module loaded
libphy: Fixed MDIO Bus: probed
davinci_mdio 1e24000.mdio: davinci mdio revision 1.5, bus freq 2200000 davinci_mdio 1e24000.mdio: no live phy, scanning all
davinci_mdio: probe of 1e24000.mdio failed with error -5
i2c /dev entries driver
<nothing after this>

Hi Suman,

Quoted 5 lines · Suman Anna

I tried booting your tree [3] on the OMAPL138-LCDK board. I am using NFS, and I am unable to get to the console. I don't have any issues booting latest -next branch (next-20180326) which only has the reset and clock driver related changes.

Quoted 15 lines

Here's the log towards the end of the boot..
---
pinctrl-single 1c14120.pinmux: 160 pins, size 80
Serial: 8250/16550 driver, 3 ports, IRQ sharing disabled console [ttyS2] disabled
1d0d000.serial: ttyS2 at MMIO 0x1d0d000 (irq = 61, base_baud = 8250000) is a TI DA8xx/66AK2x
console [ttyS2] enabled
brd: module loaded
libphy: Fixed MDIO Bus: probed
davinci_mdio 1e24000.mdio: davinci mdio revision 1.5, bus freq 2200000 davinci_mdio 1e24000.mdio: no live phy, scanning all
davinci_mdio: probe of 1e24000.mdio failed with error -5
i2c /dev entries driver
<nothing after this>

This is because of a bug in bootloader PLL configuration which got uncovered only with CCF conversion. The bootloader that comes pre-flashed with the board or the latest U-Boot master should work fine.

Here is the log with latest U-Boot master:
https://pastebin.ubuntu.com/p/HkwY9g4YDc/

2018-03-23 18:08 GMT+01:00 Stephen Boyd <[email protected]>:

Quoted 38 lines

Quoting Bartosz Golaszewski (2018-03-23 09:55:47)

Quoted 36 lines

2018-03-23 17:49 GMT+01:00 Stephen Boyd <[email protected]>:

Quoted 21 lines

Quoting Bartosz Golaszewski (2018-03-23 06:04:47)

Quoted 20 lines

From: Bartosz Golaszewski <[email protected]>

This series converts the only user of the handcoded, mach-specific reset routines in the davinci platform to using the reset framework.

Patch 1 modifies the way lookup entries are registered with the reset framework.

Patches 2-4 add necessary lookups/DT-properties.

Patches 5-7 convert the davinci-rproc driver to the reset framework.

Patch 8 removes now dead code.

Philipp: it turned out that it's indeed better to use the reset controller's device name for the entry lookup.

Tested both in DT and legacy modes by booting the examples from ti-ipc-rtos recipe in meta-ti.

Quoted 8 lines

Quoted 5 lines

This series applies on top of David Lechner's common-clk-v9 branch[1] with Philipp Zabel's reset/next branch[2] pulled in.

It can be found in my github tree as well[3].

What's the merge strategy for the rest of the patches? I should apply the clk ones after the next -rc1?

Or maybe Philipp can provide us with an immutable branch with the reset patches?

The you could apply the driver patches and let Sekhar take all the platform code?

Quoted 1 line

Ok that could work too.

Ohad, Bjorn can you ack the remoteproc patches? Are you OK with Stephen taking them through the clock tree? Otherwise it would get complicated since they depend on the first clk patch and the last clk patch depends on them.

Hi Bart,

Quoted 39 lines · Bartosz Golaszewski

2018-03-23 18:08 GMT+01:00 Stephen Boyd <[email protected]>:

Quoted 38 lines

Quoting Bartosz Golaszewski (2018-03-23 09:55:47)

Quoted 36 lines

2018-03-23 17:49 GMT+01:00 Stephen Boyd <[email protected]>:

Quoted 21 lines

Quoting Bartosz Golaszewski (2018-03-23 06:04:47)

Quoted 20 lines

From: Bartosz Golaszewski <[email protected]>

This series converts the only user of the handcoded, mach-specific reset routines in the davinci platform to using the reset framework.

Patch 1 modifies the way lookup entries are registered with the reset framework.

Patches 2-4 add necessary lookups/DT-properties.

Patches 5-7 convert the davinci-rproc driver to the reset framework.

Patch 8 removes now dead code.

Philipp: it turned out that it's indeed better to use the reset controller's device name for the entry lookup.

Tested both in DT and legacy modes by booting the examples from ti-ipc-rtos recipe in meta-ti.

Quoted 8 lines

Quoted 5 lines

This series applies on top of David Lechner's common-clk-v9 branch[1] with Philipp Zabel's reset/next branch[2] pulled in.

It can be found in my github tree as well[3].

What's the merge strategy for the rest of the patches? I should apply the clk ones after the next -rc1?

Or maybe Philipp can provide us with an immutable branch with the reset patches?

The you could apply the driver patches and let Sekhar take all the platform code?

Quoted 6 lines

Quoted 1 line

Ok that could work too.

Ohad, Bjorn can you ack the remoteproc patches? Are you OK with Stephen taking them through the clock tree? Otherwise it would get complicated since they depend on the first clk patch and the last clk patch depends on them.

I will not be queuing the DTS patches for v4.17. They depend on clock framework DTS patches which itself I plan to queue for v4.18. Given this, I think the best bet is:

Ohad/Bjorn queue remoteproc patches already acked by Suman and having no dependencies. That is, 5/8 and 6/8.

If Philipp can provide an immutable branch with reset changes, it will be great and Stephen can queue 4/8. If not, its best to resend that patch to Stephen once v4.17-rc1 is out.

Hi Bart,

Quoted 39 lines · Bartosz Golaszewski

2018-03-23 18:08 GMT+01:00 Stephen Boyd <[email protected]>:

Quoted 38 lines

Quoting Bartosz Golaszewski (2018-03-23 09:55:47)

Quoted 36 lines

2018-03-23 17:49 GMT+01:00 Stephen Boyd <[email protected]>:

Quoted 21 lines

Quoting Bartosz Golaszewski (2018-03-23 06:04:47)

Quoted 20 lines

From: Bartosz Golaszewski <[email protected]>

This series converts the only user of the handcoded, mach-specific reset routines in the davinci platform to using the reset framework.

Patch 1 modifies the way lookup entries are registered with the reset framework.

Patches 2-4 add necessary lookups/DT-properties.

Patches 5-7 convert the davinci-rproc driver to the reset framework.

Patch 8 removes now dead code.

Philipp: it turned out that it's indeed better to use the reset controller's device name for the entry lookup.

Tested both in DT and legacy modes by booting the examples from ti-ipc-rtos recipe in meta-ti.

Quoted 8 lines

Quoted 5 lines

This series applies on top of David Lechner's common-clk-v9 branch[1] with Philipp Zabel's reset/next branch[2] pulled in.

It can be found in my github tree as well[3].

What's the merge strategy for the rest of the patches? I should apply the clk ones after the next -rc1?

Or maybe Philipp can provide us with an immutable branch with the reset patches?

The you could apply the driver patches and let Sekhar take all the platform code?

Quoted 6 lines

Quoted 1 line

Ok that could work too.

Ohad, Bjorn can you ack the remoteproc patches? Are you OK with Stephen taking them through the clock tree? Otherwise it would get complicated since they depend on the first clk patch and the last clk patch depends on them.

I will not be queuing the DTS patches for v4.17. They depend on clock framework DTS patches which itself I plan to queue for v4.18. Given this, I think the best bet is:

Ohad/Bjorn queue remoteproc patches already acked by Suman and having no dependencies. That is, 5/8 and 6/8.

If Philipp can provide an immutable branch with reset changes, it will be great and Stephen can queue 4/8. If not, its best to resend that patch to Stephen once v4.17-rc1 is out.

The remaining patches need to wait till v4.18 (or even v4.19 if dependencies don't pan out well).

Thanks,
Sekhar