[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1c1e67fd-1eaa-30f5-8b2a-41a7e3ff664a@ti.com>
Date: Fri, 10 Mar 2023 21:06:21 +0530
From: Md Danish Anwar <a0501179@...com>
To: Roger Quadros <rogerq@...nel.org>,
MD Danish Anwar <danishanwar@...com>,
"Andrew F. Davis" <afd@...com>, Suman Anna <s-anna@...com>,
Vignesh Raghavendra <vigneshr@...com>,
Mathieu Poirier <mathieu.poirier@...aro.org>,
Bjorn Andersson <andersson@...nel.org>,
Santosh Shilimkar <ssantosh@...nel.org>,
Nishanth Menon <nm@...com>
CC: <linux-remoteproc@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>,
<linux-kernel@...r.kernel.org>, <linux-omap@...r.kernel.org>,
<srk@...com>, <devicetree@...r.kernel.org>,
<netdev@...r.kernel.org>
Subject: Re: [EXTERNAL] Re: [EXTERNAL] Re: [EXTERNAL] Re: [PATCH v3 3/6] soc:
ti: pruss: Add pruss_cfg_read()/update() API
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@...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@...com>
>>>>>>> Co-developed-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@...aro.org>
>>>>>>> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@...aro.org>
>>>>>>> Signed-off-by: Puranjay Mohan <p-mohan@...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.
Powered by blists - more mailing lists