public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Ben Levinsky <ben.levinsky@xilinx.com>
Cc: arnaud.pouliquen@foss.st.com, bill.mills@linaro.com,
	tanmay.shah@amd.com, linux-remoteproc@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 1/1] remoteproc: Introduce rproc_get_by_id API
Date: Fri, 25 Nov 2022 11:05:09 -0700	[thread overview]
Message-ID: <20221125180509.GA622847@p14s> (raw)
In-Reply-To: <20221115153753.2065803-2-ben.levinsky@xilinx.com>

Hi Ben,

On Tue, Nov 15, 2022 at 07:37:53AM -0800, Ben Levinsky wrote:
> Allow users of remoteproc the ability to get a handle to an rproc by
> passing in node that has parent rproc device and an ID that matches
> an expected rproc struct's index field.
> 
> This enables to get rproc structure for remoteproc drivers that manage
> more than 1 remote processor (e.g. TI and Xilinx R5 drivers).
> 
> Signed-off-by: Ben Levinsky <ben.levinsky@xilinx.com>
> ---
>  drivers/remoteproc/remoteproc_core.c | 64 +++++++++++++++++++++++++++-
>  include/linux/remoteproc.h           |  1 +
>  2 files changed, 64 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> index 775df165eb45..6f7058bcc80c 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -40,6 +40,7 @@
>  #include <linux/virtio_ring.h>
>  #include <asm/byteorder.h>
>  #include <linux/platform_device.h>
> +#include <linux/of_platform.h>
>  
>  #include "remoteproc_internal.h"
>  
> @@ -2203,13 +2204,74 @@ struct rproc *rproc_get_by_phandle(phandle phandle)
>  
>  	return rproc;
>  }
> +
> +/**
> + * rproc_get_by_id() - find a remote processor by ID
> + * @phandle: phandle to the rproc
> + * @id: Index into rproc list that uniquely identifies the rproc struct
> + *
> + * Finds an rproc handle using the remote processor's index, and then
> + * return a handle to the rproc. Before returning, ensure that the
> + * parent node's driver is still loaded.
> + *
> + * This function increments the remote processor's refcount, so always
> + * use rproc_put() to decrement it back once rproc isn't needed anymore.
> + *
> + * Return: rproc handle on success, and NULL on failure
> + */
> +
> +struct rproc *rproc_get_by_id(phandle phandle, unsigned int id)
> +{
> +	struct rproc *rproc = NULL, *r;
> +	struct platform_device *parent_pdev;
> +	struct device_node *np;
> +
> +	np = of_find_node_by_phandle(phandle);
> +	if (!np)
> +		return NULL;
> +
> +	parent_pdev = of_find_device_by_node(np->parent);
> +	if (!parent_pdev) {
> +		dev_err(&parent_pdev->dev,
> +			"no platform device for node %pOF\n", np);
> +		of_node_put(np);
> +		return NULL;
> +	}
> +
> +	/* prevent underlying implementation from being removed */
> +	if (!try_module_get(parent_pdev->dev.driver->owner)) {
> +		dev_err(&parent_pdev->dev, "can't get owner\n");
> +		of_node_put(np);
> +		return NULL;
> +	}
> +
> +	rcu_read_lock();
> +	list_for_each_entry_rcu(r, &rproc_list, node) {
> +		if (r->index == id) {
> +			rproc = r;
> +			get_device(&rproc->dev);
> +			break;
> +		}
> +	}

This won't work because several remote processors can be on the list.  If
another remote processor was discovered before the one @phandle is associated
with, the remote processor pertaining to that previous one will returned.

There is also an issue with rproc_put().  

I think your description of the problem is mostly correct.  The intermediate
devices created by the cascading entries for individual remote processors in the
device tree are causing an issue.  The "compatible" string for each remote
processor can't be handled by any platform drivers (as it should be), which
makes try_module_get() fail because r->dev.parent->driver is not bound to
anything.

Looking at the code for Xilinx's R5F support that I just queued[1], the simplest
solution may be to pass @dev, which is in fact @cluster->dev, to
zynqmp_r5_add_rproc_core() rather than the device associated with the
intermediate platform device.

That _should_ work.  It is hard for me to know for sure since I don't have a
platform that has dual core remote processor to test with.

Get back to me with how that turned out and we'll go from there.

Thanks,
Mathieu

[1]. https://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux.git/tree/drivers/remoteproc/xlnx_r5_remoteproc.c?h=rproc-next#n923

> +	rcu_read_unlock();
> +
> +	of_node_put(np);
> +
> +	return rproc;
> +}
> +EXPORT_SYMBOL(rproc_get_by_id);
>  #else
>  struct rproc *rproc_get_by_phandle(phandle phandle)
>  {
>  	return NULL;
>  }
> -#endif
>  EXPORT_SYMBOL(rproc_get_by_phandle);
> +struct rproc *rproc_get_by_id(phandle phandle, unsigned int id)
> +{
> +	return NULL;
> +}
> +EXPORT_SYMBOL(rproc_get_by_id);
> +#endif
>  
>  /**
>   * rproc_set_firmware() - assign a new firmware
> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
> index 3cde845ba26e..10961fae0f77 100644
> --- a/include/linux/remoteproc.h
> +++ b/include/linux/remoteproc.h
> @@ -645,6 +645,7 @@ struct rproc_vdev {
>  };
>  
>  struct rproc *rproc_get_by_phandle(phandle phandle);
> +struct rproc *rproc_get_by_id(phandle phandle, unsigned int id);
>  struct rproc *rproc_get_by_child(struct device *dev);
>  
>  struct rproc *rproc_alloc(struct device *dev, const char *name,
> -- 
> 2.25.1
> 

  reply	other threads:[~2022-11-25 18:05 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-15 15:37 [RFC PATCH 0/1] remoteproc: Enable getter for drivers that manage 2+ remotes Ben Levinsky
2022-11-15 15:37 ` [RFC PATCH 1/1] remoteproc: Introduce rproc_get_by_id API Ben Levinsky
2022-11-25 18:05   ` Mathieu Poirier [this message]
2022-11-30 21:39     ` Levinsky, Ben
2022-12-02 17:00       ` Mathieu Poirier
     [not found]         ` <ba21b0e5-80e2-d976-1bf3-98a91825086b@amd.com>
2022-12-08 19:05           ` Mathieu Poirier
2022-12-09 19:01             ` Ben Levinsky
2022-12-13 21:53               ` Mathieu Poirier
2022-12-13 22:21                 ` Mathieu Poirier
     [not found]                   ` <D93BFC0C-F90C-413E-899F-9CF5C6FB794A@amd.com>
2022-12-14 17:17                     ` Ben Levinsky
2022-12-14 20:17                       ` Mathieu Poirier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221125180509.GA622847@p14s \
    --to=mathieu.poirier@linaro.org \
    --cc=arnaud.pouliquen@foss.st.com \
    --cc=ben.levinsky@xilinx.com \
    --cc=bill.mills@linaro.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=tanmay.shah@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox