netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Roger Quadros <rogerq@kernel.org>
To: Md Danish Anwar <a0501179@ti.com>, Andrew Davis <afd@ti.com>,
	MD Danish Anwar <danishanwar@ti.com>, Suman Anna <s-anna@ti.com>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Mathieu Poirier <mathieu.poirier@linaro.org>,
	Bjorn Andersson <andersson@kernel.org>,
	Santosh Shilimkar <ssantosh@kernel.org>,
	Nishanth Menon <nm@ti.com>
Cc: linux-remoteproc@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
	srk@ti.com, devicetree@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [EXTERNAL] Re: [PATCH v4 2/5] soc: ti: pruss: Add pruss_{request,release}_mem_region() API
Date: Tue, 21 Mar 2023 11:24:42 +0200	[thread overview]
Message-ID: <67dd1d04-147d-0e40-c06b-6e1e0dd05f13@kernel.org> (raw)
In-Reply-To: <5b936f1b-3c5b-30ab-7074-e202fd6555b6@ti.com>

Hi,

On 21/03/2023 07:23, Md Danish Anwar wrote:
> Hi Andrew, Roger,
> 
> On 20/03/23 21:48, Andrew Davis wrote:
>> On 3/20/23 12:11 AM, Md Danish Anwar wrote:
>>> Hi Roger,
>>>
>>> On 17/03/23 14:26, Roger Quadros wrote:
>>>> Hi Andrew & Danish,
>>>>
>>>>
>>>> On 13/03/2023 13:11, MD Danish Anwar wrote:
>>>>> From: "Andrew F. Davis" <afd@ti.com>
>>>>>
>>>>> Add two new API - pruss_request_mem_region() & pruss_release_mem_region(),
>>>>> to the PRUSS platform driver to allow client drivers to acquire and release
>>>>> the common memory resources present within a PRU-ICSS subsystem. This
>>>>> allows the client drivers to directly manipulate the respective memories,
>>>>> as per their design contract with the associated firmware.
>>>>>
>>>>> Co-developed-by: Suman Anna <s-anna@ti.com>
>>>>> Signed-off-by: Suman Anna <s-anna@ti.com>
>>>>> Signed-off-by: Andrew F. Davis <afd@ti.com>
>>>>> Co-developed-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
>>>>> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
>>>>> Signed-off-by: MD Danish Anwar <danishanwar@ti.com>
>>>>> Reviewed-by: Roger Quadros <rogerq@kernel.org>
>>>>> ---
>>>>>   drivers/soc/ti/pruss.c           | 77 ++++++++++++++++++++++++++++++++
>>>>>   include/linux/pruss_driver.h     | 27 +++--------
>>>>>   include/linux/remoteproc/pruss.h | 39 ++++++++++++++++
>>>>
>>>>
>>>> We have these 2 header files and I think anything that deals with
>>>> 'struct pruss' should go in include/linux/pruss_driver.h
>>>>
>>>> Anything that deals with pru_rproc (i.e. struct rproc) should go in
>>>> include/linux/remoteproc/pruss.h
>>>>
>>>> Do you agree?
>>>>
>>>
>>> I agree with you Roger but Andrew is the right person to comment here as he is
>>> the author of this and several other patches.
>>>
>>> Hi Andrew, Can you please comment on this?
>>>
>>
>> Original idea was a consumer driver (like "ICSSG Ethernet Driver" in your other
>> series) could just
>>
>> #include <linux/remoteproc/pruss.h>
>>
>> and get everything they need, and nothing they do not.
>>
> 
> If we plan on continuing the original idea, then I think keeping the header
> files as it is will be the best. Because if we move anything that deals with
> 'struct pruss' to include/linux/pruss_driver.h and anything that deals with
> pru_rproc (i.e. struct rproc) to include/linux/remoteproc/pruss.h, then the
> consumer drivers will need to do,
> 
> #include <linux/remoteproc/pruss.h>
> #include <linux/pruss_driver.h>
> 
> Roger, should I keep the header files arrangement as it is?
> 

OK but can we please rename one of them to something else so they don't
sound very similar. Maybe you could use Andrew's suggestion below.

>> pruss_driver.h (which could be renamed pruss_internal.h) exists to allow
>> comunication between the pruss core and the pru rproc driver which live
>> in different subsystems.
>>
>> Andrew
>>
>>>>>   3 files changed, 121 insertions(+), 22 deletions(-)
>>>>>
>>>>> diff --git a/drivers/soc/ti/pruss.c b/drivers/soc/ti/pruss.c
>>>>> index a169aa1ed044..c8053c0d735f 100644
>>>>> --- a/drivers/soc/ti/pruss.c
>>>>> +++ b/drivers/soc/ti/pruss.c
>>>>> @@ -88,6 +88,82 @@ void pruss_put(struct pruss *pruss)
>>>>>   }
>>>>>   EXPORT_SYMBOL_GPL(pruss_put);
>>>>>   +/**
>>>>> + * pruss_request_mem_region() - request a memory resource
>>>>> + * @pruss: the pruss instance
>>>>> + * @mem_id: the memory resource id
>>>>> + * @region: pointer to memory region structure to be filled in
>>>>> + *
>>>>> + * This function allows a client driver to request a memory resource,
>>>>> + * and if successful, will let the client driver own the particular
>>>>> + * memory region until released using the pruss_release_mem_region()
>>>>> + * API.
>>>>> + *
>>>>> + * Return: 0 if requested memory region is available (in such case pointer to
>>>>> + * memory region is returned via @region), an error otherwise
>>>>> + */
>>>>> +int pruss_request_mem_region(struct pruss *pruss, enum pruss_mem mem_id,
>>>>> +                 struct pruss_mem_region *region)
>>>>> +{
>>>>> +    if (!pruss || !region || mem_id >= PRUSS_MEM_MAX)
>>>>> +        return -EINVAL;
>>>>> +
>>>>> +    mutex_lock(&pruss->lock);
>>>>> +
>>>>> +    if (pruss->mem_in_use[mem_id]) {
>>>>> +        mutex_unlock(&pruss->lock);
>>>>> +        return -EBUSY;
>>>>> +    }
>>>>> +
>>>>> +    *region = pruss->mem_regions[mem_id];
>>>>> +    pruss->mem_in_use[mem_id] = region;
>>>>> +
>>>>> +    mutex_unlock(&pruss->lock);
>>>>> +
>>>>> +    return 0;
>>>>> +}
>>>>> +EXPORT_SYMBOL_GPL(pruss_request_mem_region);
>>>>> +
>>>>> +/**
>>>>> + * pruss_release_mem_region() - release a memory resource
>>>>> + * @pruss: the pruss instance
>>>>> + * @region: the memory region to release
>>>>> + *
>>>>> + * This function is the complimentary function to
>>>>> + * pruss_request_mem_region(), and allows the client drivers to
>>>>> + * release back a memory resource.
>>>>> + *
>>>>> + * Return: 0 on success, an error code otherwise
>>>>> + */
>>>>> +int pruss_release_mem_region(struct pruss *pruss,
>>>>> +                 struct pruss_mem_region *region)
>>>>> +{
>>>>> +    int id;
>>>>> +
>>>>> +    if (!pruss || !region)
>>>>> +        return -EINVAL;
>>>>> +
>>>>> +    mutex_lock(&pruss->lock);
>>>>> +
>>>>> +    /* find out the memory region being released */
>>>>> +    for (id = 0; id < PRUSS_MEM_MAX; id++) {
>>>>> +        if (pruss->mem_in_use[id] == region)
>>>>> +            break;
>>>>> +    }
>>>>> +
>>>>> +    if (id == PRUSS_MEM_MAX) {
>>>>> +        mutex_unlock(&pruss->lock);
>>>>> +        return -EINVAL;
>>>>> +    }
>>>>> +
>>>>> +    pruss->mem_in_use[id] = NULL;
>>>>> +
>>>>> +    mutex_unlock(&pruss->lock);
>>>>> +
>>>>> +    return 0;
>>>>> +}
>>>>> +EXPORT_SYMBOL_GPL(pruss_release_mem_region);
>>>>> +
>>>>>   static void pruss_of_free_clk_provider(void *data)
>>>>>   {
>>>>>       struct device_node *clk_mux_np = data;
>>>>> @@ -290,6 +366,7 @@ static int pruss_probe(struct platform_device *pdev)
>>>>>           return -ENOMEM;
>>>>>         pruss->dev = dev;
>>>>> +    mutex_init(&pruss->lock);
>>>>>         child = of_get_child_by_name(np, "memories");
>>>>>       if (!child) {
>>>>> diff --git a/include/linux/pruss_driver.h b/include/linux/pruss_driver.h
>>>>> index 86242fb5a64a..22b4b37d2536 100644
>>>>> --- a/include/linux/pruss_driver.h
>>>>> +++ b/include/linux/pruss_driver.h
>>>>> @@ -9,37 +9,18 @@
>>>>>   #ifndef _PRUSS_DRIVER_H_
>>>>>   #define _PRUSS_DRIVER_H_
>>>>>   +#include <linux/mutex.h>
>>>>>   #include <linux/remoteproc/pruss.h>
>>>>>   #include <linux/types.h>
>>>>>   -/*
>>>>> - * enum pruss_mem - PRUSS memory range identifiers
>>>>> - */
>>>>> -enum pruss_mem {
>>>>> -    PRUSS_MEM_DRAM0 = 0,
>>>>> -    PRUSS_MEM_DRAM1,
>>>>> -    PRUSS_MEM_SHRD_RAM2,
>>>>> -    PRUSS_MEM_MAX,
>>>>> -};
>>>>> -
>>>>> -/**
>>>>> - * struct pruss_mem_region - PRUSS memory region structure
>>>>> - * @va: kernel virtual address of the PRUSS memory region
>>>>> - * @pa: physical (bus) address of the PRUSS memory region
>>>>> - * @size: size of the PRUSS memory region
>>>>> - */
>>>>> -struct pruss_mem_region {
>>>>> -    void __iomem *va;
>>>>> -    phys_addr_t pa;
>>>>> -    size_t size;
>>>>> -};
>>>>> -
>>>>>   /**
>>>>>    * struct pruss - PRUSS parent structure
>>>>>    * @dev: pruss device pointer
>>>>>    * @cfg_base: base iomap for CFG region
>>>>>    * @cfg_regmap: regmap for config region
>>>>>    * @mem_regions: data for each of the PRUSS memory regions
>>>>> + * @mem_in_use: to indicate if memory resource is in use
>>>>> + * @lock: mutex to serialize access to resources
>>>>>    * @core_clk_mux: clk handle for PRUSS CORE_CLK_MUX
>>>>>    * @iep_clk_mux: clk handle for PRUSS IEP_CLK_MUX
>>>>>    */
>>>>> @@ -48,6 +29,8 @@ struct pruss {
>>>>>       void __iomem *cfg_base;
>>>>>       struct regmap *cfg_regmap;
>>>>>       struct pruss_mem_region mem_regions[PRUSS_MEM_MAX];
>>>>> +    struct pruss_mem_region *mem_in_use[PRUSS_MEM_MAX];
>>>>> +    struct mutex lock; /* PRU resource lock */
>>>>>       struct clk *core_clk_mux;
>>>>>       struct clk *iep_clk_mux;
>>>>>   };
>>>>> diff --git a/include/linux/remoteproc/pruss.h
>>>>> b/include/linux/remoteproc/pruss.h
>>>>> index 93a98cac7829..33f930e0a0ce 100644
>>>>> --- a/include/linux/remoteproc/pruss.h
>>>>> +++ b/include/linux/remoteproc/pruss.h
>>>>> @@ -44,6 +44,28 @@ enum pru_ctable_idx {
>>>>>       PRU_C31,
>>>>>   };
>>>>>   +/*
>>>>> + * enum pruss_mem - PRUSS memory range identifiers
>>>>> + */
>>>>> +enum pruss_mem {
>>>>> +    PRUSS_MEM_DRAM0 = 0,
>>>>> +    PRUSS_MEM_DRAM1,
>>>>> +    PRUSS_MEM_SHRD_RAM2,
>>>>> +    PRUSS_MEM_MAX,
>>>>> +};
>>>>> +
>>>>> +/**
>>>>> + * struct pruss_mem_region - PRUSS memory region structure
>>>>> + * @va: kernel virtual address of the PRUSS memory region
>>>>> + * @pa: physical (bus) address of the PRUSS memory region
>>>>> + * @size: size of the PRUSS memory region
>>>>> + */
>>>>> +struct pruss_mem_region {
>>>>> +    void __iomem *va;
>>>>> +    phys_addr_t pa;
>>>>> +    size_t size;
>>>>> +};
>>>>> +
>>>>>   struct device_node;
>>>>>   struct rproc;
>>>>>   struct pruss;
>>>>> @@ -52,6 +74,10 @@ struct pruss;
>>>>>     struct pruss *pruss_get(struct rproc *rproc);
>>>>>   void pruss_put(struct pruss *pruss);
>>>>> +int pruss_request_mem_region(struct pruss *pruss, enum pruss_mem mem_id,
>>>>> +                 struct pruss_mem_region *region);
>>>>> +int pruss_release_mem_region(struct pruss *pruss,
>>>>> +                 struct pruss_mem_region *region);
>>>>>     #else
>>>>>   @@ -62,6 +88,19 @@ static inline struct pruss *pruss_get(struct rproc
>>>>> *rproc)
>>>>>     static inline void pruss_put(struct pruss *pruss) { }
>>>>>   +static inline int pruss_request_mem_region(struct pruss *pruss,
>>>>> +                       enum pruss_mem mem_id,
>>>>> +                       struct pruss_mem_region *region)
>>>>> +{
>>>>> +    return -EOPNOTSUPP;
>>>>> +}
>>>>> +
>>>>> +static inline int pruss_release_mem_region(struct pruss *pruss,
>>>>> +                       struct pruss_mem_region *region)
>>>>> +{
>>>>> +    return -EOPNOTSUPP;
>>>>> +}
>>>>> +
>>>>>   #endif /* CONFIG_TI_PRUSS */
>>>>>     #if IS_ENABLED(CONFIG_PRU_REMOTEPROC)
>>>>
>>>> cheers,
>>>> -roger
>>>
> 

cheers,
-roger

  reply	other threads:[~2023-03-21  9:24 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-13 11:11 [PATCH v4 0/5] Introduce PRU platform consumer API MD Danish Anwar
2023-03-13 11:11 ` [PATCH v4 1/5] soc: ti: pruss: Add pruss_get()/put() API MD Danish Anwar
2023-03-13 16:19   ` Andrew Davis
2023-03-13 11:11 ` [PATCH v4 2/5] soc: ti: pruss: Add pruss_{request,release}_mem_region() API MD Danish Anwar
2023-03-17  8:56   ` Roger Quadros
2023-03-20  5:11     ` [EXTERNAL] " Md Danish Anwar
2023-03-20 16:18       ` Andrew Davis
2023-03-21  5:23         ` Md Danish Anwar
2023-03-21  9:24           ` Roger Quadros [this message]
2023-03-21  9:48             ` [EXTERNAL] " Md Danish Anwar
2023-03-21 10:23               ` Roger Quadros
2023-03-21 10:45                 ` Md Danish Anwar
2023-03-13 11:11 ` [PATCH v4 3/5] soc: ti: pruss: Add pruss_cfg_read()/update() API MD Danish Anwar
2023-03-15 12:07   ` Roger Quadros
2023-03-16 11:08     ` [EXTERNAL] " Md Danish Anwar
2023-03-16 11:29       ` Md Danish Anwar
2023-03-16 11:32         ` Roger Quadros
2023-03-16 11:34           ` [EXTERNAL] " Md Danish Anwar
2023-03-13 11:11 ` [PATCH v4 4/5] soc: ti: pruss: Add helper functions to set GPI mode, MII_RT_event and XFR MD Danish Anwar
2023-03-15 12:22   ` Roger Quadros
2023-03-16 11:05     ` [EXTERNAL] " Md Danish Anwar
2023-03-16 11:36       ` Roger Quadros
2023-03-16 11:44         ` Md Danish Anwar
2023-03-16 12:19           ` Roger Quadros
2023-03-16 13:11             ` [EXTERNAL] " Md Danish Anwar
2023-03-16 14:04               ` Roger Quadros
2023-03-17  5:02                 ` [EXTERNAL] " Md Danish Anwar
2023-03-17  8:31                   ` Roger Quadros
2023-03-17  8:55                     ` [EXTERNAL] " Md Danish Anwar
2023-03-13 11:11 ` [PATCH v4 5/5] soc: ti: pruss: Add helper functions to get/set PRUSS_CFG_GPMUX 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=67dd1d04-147d-0e40-c06b-6e1e0dd05f13@kernel.org \
    --to=rogerq@kernel.org \
    --cc=a0501179@ti.com \
    --cc=afd@ti.com \
    --cc=andersson@kernel.org \
    --cc=danishanwar@ti.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=netdev@vger.kernel.org \
    --cc=nm@ti.com \
    --cc=s-anna@ti.com \
    --cc=srk@ti.com \
    --cc=ssantosh@kernel.org \
    --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).