Re: [EXTERNAL] Re: [EXTERNAL] Re: [PATCH v11 3/6] remoteproc: pru: Add APIs to get and put the PRU cores

From: Md Danish Anwar
Date: Mon Dec 12 2022 - 04:58:05 EST

Next message: Andy Shevchenko: "Re: [PATCH v3] auxdisplay: hd44780: Fix potential memory leak in hd44780_remove()"
Previous message: Piergiorgio Beruto: "Re: [PATCH v6 net-next 3/5] drivers/net/phy: add connection between ethtool and phylib for PLCA"
In reply to: Roger Quadros: "Re: [EXTERNAL] Re: [PATCH v11 3/6] remoteproc: pru: Add APIs to get and put the PRU cores"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Hi Roger,

On 12/12/22 14:47, Roger Quadros wrote:
> 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@xxxxxx>
>>>> Signed-off-by: Tero Kristo <t-kristo@xxxxxx>
>>>> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@xxxxxxxxxx>
>>>> Signed-off-by: MD Danish Anwar <danishanwar@xxxxxx>
>>>> ---
>>>> 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@xxxxxx>
>>>> * Andrew F. Davis <afd@xxxxxx>
>>>> * Grzegorz Jaszczyk <grzegorz.jaszczyk@xxxxxxxxxx> for Texas Instruments
>>>> + * Puranjay Mohan <p-mohan@xxxxxx>
>>>> + * Md Danish Anwar <danishanwar@xxxxxx>
>>>> */
>>>>
>>>> #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?
>

Yes, from here we are going to the label err_no_rproc_handle where rproc_put()
API is called. Which is further calling put_device(). So essentially we are
doing two put device instead of one.

So I think, I should remove the put_device() from the below if block

if (pru->client_np) {
mutex_unlock(&pru->lock);
put_device(dev);
ret = -EBUSY;
goto err_no_rproc_handle;
}

>>
>>>> + 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

Next message: Andy Shevchenko: "Re: [PATCH v3] auxdisplay: hd44780: Fix potential memory leak in hd44780_remove()"
Previous message: Piergiorgio Beruto: "Re: [PATCH v6 net-next 3/5] drivers/net/phy: add connection between ethtool and phylib for PLCA"
In reply to: Roger Quadros: "Re: [EXTERNAL] Re: [PATCH v11 3/6] remoteproc: pru: Add APIs to get and put the PRU cores"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]