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
