Hi Danish,
On 10/03/2023 17:36, Md Danish Anwar wrote:
> 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@xxxxxx>
>>>>>>>>
>>>>>>>> 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);
> }
I would suggest to make separate APIs for PRU XFR vs RTU XFR.
>
> 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)
Need to declare this as 'static'.
>
>
>
> 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,
this as well.
>
>
>
> 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.
>
Rest looks OK.
cheers,
-roger
