On 13/03/2023 07:01, Md Danish Anwar wrote:
> Hi Roger
>
> On 11/03/23 17:36, Roger Quadros wrote:
>> 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.
>>
>
> How about making only one API for XFR shift and passing PRU or RTU as argument
> to the API. The API along with struct pruss and bool enable will take another
> argument u32 mask.
>
> mask = PRUSS_SPP_XFER_SHIFT_EN for PRU
> mask = PRUSS_SPP_RTU_XFR_SHIFT_EN for RTU
> mask = PRUSS_SPP_XFER_SHIFT_EN | PRUSS_SPP_RTU_XFR_SHIFT_EN for PRU and RTU
>
> So one API will be able to do all three jobs.
>
> How does this seem?
Yes, that is also fine.
cheers,
-roger
