Thread (17 messages) 17 messages, 4 authors, 2020-09-21

Re: [PATCH v14 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

From: Michael Auchter <hidden>
Date: 2020-09-17 22:29:37
Also in: linux-devicetree, linux-remoteproc, lkml

Hey Ben,

Split mode is still not functional in this patch series (as was the case
with the last few revisions).

Before sending out the next revision, can you _please_ ensure you're
testing all supported configurations?

On Thu, Sep 17, 2020 at 12:43:41PM -0700, Ben Levinsky wrote:
+/**
+ * RPU core configuration
+ */
+static enum rpu_oper_mode rpu_mode;
+
<.. snip ..>
+static int zynqmp_r5_remoteproc_probe(struct platform_device *pdev)
+{
+	int ret, i = 0;
+	u32 lockstep_mode;
+	struct device *dev = &pdev->dev;
+	struct device_node *nc;
+
+	ret = of_property_read_u32(dev->of_node,
+				   "lockstep-mode",
+				   &lockstep_mode);
+	if (ret < 0) {
+		return ret;
+	} else if (lockstep_mode != PM_RPU_MODE_LOCKSTEP &&
+	    lockstep_mode != PM_RPU_MODE_SPLIT) {
+		dev_err(dev,
+			"Invalid lockstep-mode %x in %pOF\n",
+			lockstep_mode, dev->of_node);
+		return -EINVAL;
+	}
+
+	rpu_mode = lockstep_mode;
+
+	dev_dbg(dev, "RPU configuration: %s\n",
+		lockstep_mode ? "lockstep" : "split");
The binding documents lockstep-mode as:
+  lockstep-mode:
+    description:
+      R5 core configuration (split is 0 or lock-step and 1)
+    maxItems: 1
(Which needs to be reworded, but it looks like the intent was "split is
0 and lock-step is 1")

However, rpu_oper_mode is defined as:
+enum rpu_oper_mode {
+       PM_RPU_MODE_LOCKSTEP = 0,
+       PM_RPU_MODE_SPLIT = 1,
+};
so the assignment "rpu_mode = lockstep_mode" is incorrect.

- Michael

_______________________________________________
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