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