linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Md Danish Anwar <a0501179@ti.com>
To: Roger Quadros <rogerq@kernel.org>,
	MD Danish Anwar <danishanwar@ti.com>,
	"Andrew F. Davis" <afd@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: [EXTERNAL] Re: [EXTERNAL] Re: [PATCH v3 3/6] soc: ti: pruss: Add pruss_cfg_read()/update() API
Date: Fri, 10 Mar 2023 21:06:21 +0530	[thread overview]
Message-ID: <1c1e67fd-1eaa-30f5-8b2a-41a7e3ff664a@ti.com> (raw)
In-Reply-To: <46415d8e-3c92-d489-3f44-01a586160082@kernel.org>

Hi Roger,

On 10/03/23 18:53, Roger Quadros wrote:
> Hi Danish,
> 
> On 10/03/2023 13:53, Md Danish Anwar wrote:
>> Hi Roger,
>>
>> On 09/03/23 17:00, Md Danish Anwar wrote:
>>> Hi Roger,
>>>
>>> On 08/03/23 17:12, Roger Quadros wrote:
>>>>
>>>>
>>>> On 08/03/2023 13:36, Md Danish Anwar wrote:
>>>>> Hi Roger,
>>>>>
>>>>> On 08/03/23 13:57, Roger Quadros wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 06/03/2023 13:09, MD Danish Anwar wrote:
>>>>>>> From: Suman Anna <s-anna@ti.com>
>>>>>>>
>>>>>>> Add two new generic API pruss_cfg_read() and pruss_cfg_update() to
>>>>>>> the PRUSS platform driver to allow other drivers to read and program
>>>>>>> respectively a register within the PRUSS CFG sub-module represented
>>>>>>> by a syscon driver. This interface provides a simple way for client
>>>>>>
>>>>>> Do you really need these 2 functions to be public?
>>>>>> I see that later patches (4-6) add APIs for doing specific things
>>>>>> and that should be sufficient than exposing entire CFG space via
>>>>>> pruss_cfg_read/update().
>>>>>>
>>>>>>
>>>>>
>>>>> I think the intention here is to keep this APIs pruss_cfg_read() and
>>>>> pruss_cfg_update() public so that other drivers can read / modify PRUSS config
>>>>> when needed.
>>>>
>>>> Where are these other drivers? If they don't exist then let's not make provision
>>>> for it now.
>>>> We can provide necessary API helpers when needed instead of letting client drivers
>>>> do what they want as they can be misused and hard to debug.
>>>>
>>>
>>> The ICSSG Ethernet driver uses pruss_cfg_update() API. It is posted upstream in
>>> the series [1]. The ethernet driver series is dependent on this series. In
>>> series [1] we are using pruss_cfg_update() in icssg_config.c file,
>>> icssg_config() API.
> 
> You can instead add a new API on what exactly you want it to do rather than exposing
> entire CFG space.
> 

Sure.

In icssg_config.c, a call to pruss_cfg_update() is made to enable XFR shift for
PRU and RTU,

	/* enable XFR shift for PRU and RTU */
	mask = PRUSS_SPP_XFER_SHIFT_EN | PRUSS_SPP_RTU_XFR_SHIFT_EN;
	pruss_cfg_update(prueth->pruss, PRUSS_CFG_SPP, mask, mask);

I will add the below API as part of Patch 4 of the series. We'll call this API
and entire CFG space will not be exposed.

/**
 * pruss_cfg_xfr_pru_rtu_enable() - Enable/disable XFR shift for PRU and RTU
 * @pruss: the pruss instance
 * @enable: enable/disable
 *
 * Return: 0 on success, or an error code otherwise
 */
static inline int pruss_cfg_xfr_pru_rtu_enable(struct pruss *pruss, bool enable)
{
	u32 mask = PRUSS_SPP_XFER_SHIFT_EN | PRUSS_SPP_RTU_XFR_SHIFT_EN;
	u32 set = enable ? mask : 0;

	return pruss_cfg_update(pruss, PRUSS_CFG_SPP, mask, set);
}

To make pruss_cfg_update() and pruss_cfg_read() API internal to pruss.c, I will
add the below change to pruss.h file and pruss.c file. Let me know if this
change looks okay to you.

diff --git a/drivers/soc/ti/pruss.c b/drivers/soc/ti/pruss.c

index 537a3910ffd8..9f01c8809deb 100644

--- a/drivers/soc/ti/pruss.c

+++ b/drivers/soc/ti/pruss.c

@@ -182,7 +182,6 @@ int pruss_cfg_read(struct pruss *pruss, unsigned int reg,
unsigned int *val)



        return regmap_read(pruss->cfg_regmap, reg, val);

 }

-EXPORT_SYMBOL_GPL(pruss_cfg_read);



 /**

  * pruss_cfg_update() - configure a PRUSS CFG sub-module register

@@ -203,7 +202,6 @@ int pruss_cfg_update(struct pruss *pruss, unsigned int reg,



        return regmap_update_bits(pruss->cfg_regmap, reg, mask, val);

 }

-EXPORT_SYMBOL_GPL(pruss_cfg_update);



 static void pruss_of_free_clk_provider(void *data)

 {

diff --git a/include/linux/remoteproc/pruss.h b/include/linux/remoteproc/pruss.h

index d41bec448f06..12ef10b9fe9a 100644

--- a/include/linux/remoteproc/pruss.h

+++ b/include/linux/remoteproc/pruss.h

@@ -165,9 +165,6 @@ 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);

-int pruss_cfg_read(struct pruss *pruss, unsigned int reg, unsigned int *val);

-int pruss_cfg_update(struct pruss *pruss, unsigned int reg,

-                    unsigned int mask, unsigned int val);



 #else



@@ -191,18 +188,6 @@ static inline int pruss_release_mem_region(struct pruss
*pruss,

        return -EOPNOTSUPP;

 }



-static inline int pruss_cfg_read(struct pruss *pruss, unsigned int reg,

-                                unsigned int *val)

-{

-       return -EOPNOTSUPP;

-}

-

-static inline int pruss_cfg_update(struct pruss *pruss, unsigned int reg,

-                                  unsigned int mask, unsigned int val)

-{

-       return -EOPNOTSUPP;

-}

-

 #endif /* CONFIG_TI_PRUSS */



 #if IS_ENABLED(CONFIG_PRU_REMOTEPROC)


Please have a look and let me know if above API and code changes looks OK to you.

>>>
>>> So for this, the API pruss_cfg_update() needs to be public.
>>>
>>> [1] https://lore.kernel.org/all/20230210114957.2667963-3-danishanwar@ti.com/
>>>
>>
>> I will keep this patch as it is as pruss_cfg_update() needs to be public for
>> ICSSG Ethernet driver and pruss_cfg_read() is kind of a complementary function
>> to update. I will do required changes in other patches and send next revision
>> if that's OK with you. Please let me know.
>>
>>>>>
>>>>> The later patches (4-6) add APIs to do specific thing, but those APIs also
>>>>> eventually call pruss_cfg_read/update().
>>>>
>>>> They can still call them but they need to be private to pruss.c
>>>>
>>>>>
>>>>>>> drivers without having them to include and parse the CFG syscon node
>>>>>>> within their respective device nodes. Various useful registers and
>>>>>>> macros for certain register bit-fields and their values have also
>>>>>>> been added.
>>>>>>>
>>>>>>> It is the responsibility of the client drivers to reconfigure or
>>>>>>> reset a particular register upon any failures.
>>>>>>>
>>>>>>> Signed-off-by: Suman Anna <s-anna@ti.com>
>>>>>>> Co-developed-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
>>>>>>> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
>>>>>>> Signed-off-by: Puranjay Mohan <p-mohan@ti.com>
>>>>>>> ---
>>>>>>>  drivers/soc/ti/pruss.c           |  41 +++++++++++++
>>>>>>>  include/linux/remoteproc/pruss.h | 102 +++++++++++++++++++++++++++++++
>>>>>>>  2 files changed, 143 insertions(+)
>>>>>>>
>>>>>>> diff --git a/drivers/soc/ti/pruss.c b/drivers/soc/ti/pruss.c
>>>>>>> index c8053c0d735f..537a3910ffd8 100644
>>>>>>> --- a/drivers/soc/ti/pruss.c
>>>>>>> +++ b/drivers/soc/ti/pruss.c
>>>>>>> @@ -164,6 +164,47 @@ int pruss_release_mem_region(struct pruss *pruss,
>>>>>>>  }
>>>>>>>  EXPORT_SYMBOL_GPL(pruss_release_mem_region);
>>>>>>
> 
> cheers,
> -roger

-- 
Thanks and Regards,
Danish.

  reply	other threads:[~2023-03-10 15:47 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-06 11:09 [PATCH v3 0/6] Introduce PRU platform consumer API MD Danish Anwar
2023-03-06 11:09 ` [PATCH v3 1/6] soc: ti: pruss: Add pruss_get()/put() API MD Danish Anwar
2023-03-08  8:22   ` Roger Quadros
2023-03-06 11:09 ` [PATCH v3 2/6] soc: ti: pruss: Add pruss_{request,release}_mem_region() API MD Danish Anwar
2023-03-08  8:23   ` Roger Quadros
2023-03-06 11:09 ` [PATCH v3 3/6] soc: ti: pruss: Add pruss_cfg_read()/update() API MD Danish Anwar
2023-03-08  8:27   ` Roger Quadros
2023-03-08 11:36     ` [EXTERNAL] " Md Danish Anwar
2023-03-08 11:42       ` Roger Quadros
2023-03-09 11:30         ` [EXTERNAL] " Md Danish Anwar
2023-03-10 11:53           ` Md Danish Anwar
2023-03-10 13:23             ` Roger Quadros
2023-03-10 15:36               ` Md Danish Anwar [this message]
2023-03-11 12:06                 ` [EXTERNAL] " Roger Quadros
2023-03-13  5:01                   ` [EXTERNAL] " Md Danish Anwar
2023-03-13  7:51                     ` Roger Quadros
2023-03-06 11:09 ` [PATCH v3 4/6] soc: ti: pruss: Add helper functions to set GPI mode, MII_RT_event and XFR MD Danish Anwar
2023-03-08  8:34   ` Roger Quadros
2023-03-08  9:23     ` [EXTERNAL] " Md Danish Anwar
2023-03-08 11:15       ` Roger Quadros
2023-03-08 11:29         ` [EXTERNAL] " Md Danish Anwar
2023-03-08 11:39           ` Roger Quadros
2023-03-06 11:09 ` [PATCH v3 5/6] soc: ti: pruss: Add helper function to enable OCP master ports MD Danish Anwar
2023-03-08  8:41   ` Roger Quadros
2023-03-08 11:09     ` [EXTERNAL] " Md Danish Anwar
2023-03-08 11:14       ` Roger Quadros
2023-03-08 11:16         ` [EXTERNAL] " Md Danish Anwar
2023-03-09  7:04   ` Tony Lindgren
2023-03-09 11:34     ` [EXTERNAL] " Md Danish Anwar
2023-03-06 11:09 ` [PATCH v3 6/6] soc: ti: pruss: Add helper functions to get/set PRUSS_CFG_GPMUX MD Danish Anwar
2023-03-08  8:43   ` Roger Quadros
2023-03-06 18:43 ` [PATCH v3 0/6] Introduce PRU platform consumer API 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=1c1e67fd-1eaa-30f5-8b2a-41a7e3ff664a@ti.com \
    --to=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=rogerq@kernel.org \
    --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).