Messages in this thread | | | Date | Thu, 17 Sep 2020 17:11:20 -0500 | From | Michael Auchter <> | Subject | Re: [PATCH v14 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver |
| |
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
| |