devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Roger Quadros <rogerq@kernel.org>
To: Md Danish Anwar <a0501179@ti.com>,
	MD Danish Anwar <danishanwar@ti.com>,
	Mathieu Poirier <mathieu.poirier@linaro.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Rob Herring <robh+dt@kernel.org>
Cc: Suman Anna <s-anna@ti.com>, "Andrew F . Davis" <afd@ti.com>,
	nm@ti.com, vigneshr@ti.com, srk@ti.com,
	linux-remoteproc@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [EXTERNAL] Re: [PATCH v11 3/6] remoteproc: pru: Add APIs to get and put the PRU cores
Date: Mon, 12 Dec 2022 11:17:44 +0200	[thread overview]
Message-ID: <7d73a0a4-c5e2-74bb-4ef9-9bc2dadd6272@kernel.org> (raw)
In-Reply-To: <a8b8ba60-0413-5568-ae9a-57c25840dca7@ti.com>

Danish,

On 09/12/2022 06:55, Md Danish Anwar wrote:
> Hi Roger,
> 
> On 08/12/22 16:05, Roger Quadros wrote:
>> Hi,
>>
>> On 07/12/2022 13:04, MD Danish Anwar wrote:
>>> Add two new APIs, pru_rproc_get() and pru_rproc_put(), to the PRU
>>> driver to allow client drivers to acquire and release the remoteproc
>>> device associated with a PRU core. The PRU cores are treated as
>>> resources with only one client owning it at a time.
>>>
>>> The pru_rproc_get() function returns the rproc handle corresponding
>>> to a PRU core identified by the device tree "ti,prus" property under
>>> the client node. The pru_rproc_put() is the complementary function
>>> to pru_rproc_get().
>>>
>>> Signed-off-by: Suman Anna <s-anna@ti.com>
>>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>>> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
>>> Signed-off-by: MD Danish Anwar <danishanwar@ti.com>
>>> ---
>>>  drivers/remoteproc/pru_rproc.c | 133 ++++++++++++++++++++++++++++++++-
>>>  include/linux/pruss.h          |  29 +++++++
>>>  2 files changed, 160 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/remoteproc/pru_rproc.c b/drivers/remoteproc/pru_rproc.c
>>> index a1a208b31846..7d4ed39b3772 100644
>>> --- a/drivers/remoteproc/pru_rproc.c
>>> +++ b/drivers/remoteproc/pru_rproc.c
>>> @@ -2,12 +2,14 @@
>>>  /*
>>>   * PRU-ICSS remoteproc driver for various TI SoCs
>>>   *
>>> - * Copyright (C) 2014-2020 Texas Instruments Incorporated - https://www.ti.com/
>>> + * Copyright (C) 2014-2022 Texas Instruments Incorporated - https://www.ti.com/
>>>   *
>>>   * Author(s):
>>>   *	Suman Anna <s-anna@ti.com>
>>>   *	Andrew F. Davis <afd@ti.com>
>>>   *	Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> for Texas Instruments
>>> + *	Puranjay Mohan <p-mohan@ti.com>
>>> + *	Md Danish Anwar <danishanwar@ti.com>
>>>   */
>>>  
>>>  #include <linux/bitops.h>
>>> @@ -112,6 +114,8 @@ struct pru_private_data {
>>>   * @rproc: remoteproc pointer for this PRU core
>>>   * @data: PRU core specific data
>>>   * @mem_regions: data for each of the PRU memory regions
>>> + * @client_np: client device node
>>> + * @lock: mutex to protect client usage
>>>   * @fw_name: name of firmware image used during loading
>>>   * @mapped_irq: virtual interrupt numbers of created fw specific mapping
>>>   * @pru_interrupt_map: pointer to interrupt mapping description (firmware)
>>> @@ -127,6 +131,8 @@ struct pru_rproc {
>>>  	struct rproc *rproc;
>>>  	const struct pru_private_data *data;
>>>  	struct pruss_mem_region mem_regions[PRU_IOMEM_MAX];
>>> +	struct device_node *client_np;
>>> +	struct mutex lock;
>>>  	const char *fw_name;
>>>  	unsigned int *mapped_irq;
>>>  	struct pru_irq_rsc *pru_interrupt_map;
>>> @@ -147,6 +153,125 @@ void pru_control_write_reg(struct pru_rproc *pru, unsigned int reg, u32 val)
>>>  	writel_relaxed(val, pru->mem_regions[PRU_IOMEM_CTRL].va + reg);
>>>  }
>>>  
>>> +static struct rproc *__pru_rproc_get(struct device_node *np, int index)
>>> +{
>>> +	struct rproc *rproc;
>>> +	phandle rproc_phandle;
>>> +	int ret;
>>> +
>>> +	ret = of_property_read_u32_index(np, "ti,prus", index, &rproc_phandle);
>>> +	if (ret)
>>> +		return ERR_PTR(ret);
>>> +
>>> +	rproc = rproc_get_by_phandle(rproc_phandle);
>>> +	if (!rproc) {
>>> +		ret = -EPROBE_DEFER;
>>> +		goto err_no_rproc_handle;
>>> +	}
>>> +
>>> +	/* make sure it is PRU rproc */
>>> +	if (!is_pru_rproc(rproc->dev.parent)) {
>>> +		rproc_put(rproc);
>>> +		return ERR_PTR(-ENODEV);
>>> +	}
>>> +
>>> +	return rproc;
>>> +
>>> +err_no_rproc_handle:
>>> +	rproc_put(rproc);
>>> +	return ERR_PTR(ret);
>>> +}
>>> +
>>> +/**
>>> + * pru_rproc_get() - get the PRU rproc instance from a device node
>>> + * @np: the user/client device node
>>> + * @index: index to use for the ti,prus property
>>> + * @pru_id: optional pointer to return the PRU remoteproc processor id
>>> + *
>>> + * This function looks through a client device node's "ti,prus" property at
>>> + * index @index and returns the rproc handle for a valid PRU remote processor if
>>> + * found. The function allows only one user to own the PRU rproc resource at a
>>> + * time. Caller must call pru_rproc_put() when done with using the rproc, not
>>> + * required if the function returns a failure.
>>> + *
>>> + * When optional @pru_id pointer is passed the PRU remoteproc processor id is
>>> + * returned.
>>> + *
>>> + * Return: rproc handle on success, and an ERR_PTR on failure using one
>>> + * of the following error values
>>> + *    -ENODEV if device is not found
>>> + *    -EBUSY if PRU is already acquired by anyone
>>> + *    -EPROBE_DEFER is PRU device is not probed yet
>>> + */
>>> +struct rproc *pru_rproc_get(struct device_node *np, int index,
>>> +			    enum pruss_pru_id *pru_id)
>>> +{
>>> +	struct rproc *rproc;
>>> +	struct pru_rproc *pru;
>>> +	struct device *dev;
>>> +	int ret;
>>> +
>>> +	rproc = __pru_rproc_get(np, index);
>>> +	if (IS_ERR(rproc))
>>> +		return rproc;
>>> +
>>> +	pru = rproc->priv;
>>> +	dev = &rproc->dev;
>>> +
>>> +	mutex_lock(&pru->lock);
>>> +
>>> +	if (pru->client_np) {
>>> +		mutex_unlock(&pru->lock);
>>> +		put_device(dev);
>>
>> Is this put_device() to counter balance the get_device() you had earlier?
>> Is it still needed?
>>> Did we do the right thing by getting rid of the additional get_device()?
>> I didn't see a reason for it.
>>
> 
> The previous get_device() in __pru_rproc_get() was additional/not required as
> the same get_device() was called by rproc_get_by_phandle() API before it's
> completion.
> 
> So that get_device() is not needed.
> 
> The put_device() here is to counter the get_device() called by
> rproc_get_by_phandle() in the API __pru_rproc_get().
> 
> So I think, this put_device() is still needed.

But at the end of this function we are calling rproc_put()
which also does a put_device(), right?

> 
>>> +		ret = -EBUSY;
>>> +		goto err_no_rproc_handle;
>>> +	}
>>> +
>>> +	pru->client_np = np;
>>> +
>>> +	mutex_unlock(&pru->lock);
>>> +
>>> +	if (pru_id)
>>> +		*pru_id = pru->id;
>>> +
>>> +	return rproc;
>>> +
>>> +err_no_rproc_handle:
>>> +	rproc_put(rproc);
>>> +	return ERR_PTR(ret);
>>> +}
>>> +EXPORT_SYMBOL_GPL(pru_rproc_get);

<snip>

cheers,
-roger

  reply	other threads:[~2022-12-12  9:19 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-07 11:04 [PATCH v11 0/6] Introduce PRU remoteproc consumer API MD Danish Anwar
2022-12-07 11:04 ` [PATCH v11 1/6] dt-bindings: remoteproc: Add PRU consumer bindings MD Danish Anwar
2022-12-07 11:04 ` [PATCH v11 2/6] remoteproc: pru: Add enum for PRU Core Identifiers MD Danish Anwar
2022-12-08 10:22   ` Roger Quadros
2022-12-07 11:04 ` [PATCH v11 3/6] remoteproc: pru: Add APIs to get and put the PRU cores MD Danish Anwar
2022-12-08 10:35   ` Roger Quadros
2022-12-09  4:55     ` [EXTERNAL] " Md Danish Anwar
2022-12-12  9:17       ` Roger Quadros [this message]
2022-12-12  9:57         ` [EXTERNAL] " Md Danish Anwar
2022-12-07 11:04 ` [PATCH v11 4/6] remoteproc: pru: Make sysfs entries read-only for PRU client driven boots MD Danish Anwar
2022-12-07 11:04 ` [PATCH v11 5/6] remoteproc: pru: Add pru_rproc_set_ctable() function MD Danish Anwar
2022-12-07 11:04 ` [PATCH v11 6/6] remoteproc: pru: Configure firmware based on client setup MD Danish Anwar

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=7d73a0a4-c5e2-74bb-4ef9-9bc2dadd6272@kernel.org \
    --to=rogerq@kernel.org \
    --cc=a0501179@ti.com \
    --cc=afd@ti.com \
    --cc=danishanwar@ti.com \
    --cc=devicetree@vger.kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=nm@ti.com \
    --cc=robh+dt@kernel.org \
    --cc=s-anna@ti.com \
    --cc=srk@ti.com \
    --cc=vigneshr@ti.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;
as well as URLs for NNTP newsgroup(s).