lkml.org 
[lkml]   [2020]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2020-09-18 00:30    [W:0.080 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site