Re: [PATCH v3 2/2] dt-bindings: soc: ti: pruss: Add documentation for PA_STATS support

[MD Danish Anwar <danishanwar@ti.com>]

On 28/06/24 12:04 pm, Nishanth Menon wrote:
> On 10:56-20240628, MD Danish Anwar wrote:
>>
>>
>> On 27/06/24 8:15 pm, Nishanth Menon wrote:
>>> On 21:03-20240625, MD Danish Anwar wrote:
>>>> Add documentation for pa-stats node which is syscon regmap for
>>>> PA_STATS registers. This will be used to dump statistics maintained by
>>>> ICSSG firmware.
>>>>
>>>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>>>> Signed-off-by: MD Danish Anwar <danishanwar@ti.com>
>>>> ---
>>>>  .../devicetree/bindings/soc/ti/ti,pruss.yaml  | 20 +++++++++++++++++++
>>>>  1 file changed, 20 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml b/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml
>>>> index c402cb2928e8..3cb1471cc6b6 100644
>>>> --- a/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml
>>>> +++ b/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml
>>>> @@ -278,6 +278,26 @@ patternProperties:
>>>>  
>>>>      additionalProperties: false
>>>>  
>>>> +  ^pa-stats@[a-f0-9]+$:
>>>> +    description: |
>>>> +      PA-STATS sub-module represented as a SysCon. PA_STATS is a set of
>>>> +      registers where different statistics related to ICSSG, are dumped by
>>>> +      ICSSG firmware. This syscon sub-module will help the device to
>>>> +      access/read/write those statistics.
>>>> +
>>>> +    type: object
>>>> +
>>>> +    additionalProperties: false
>>>> +
>>>> +    properties:
>>>> +      compatible:
>>>> +        items:
>>>> +          - const: ti,pruss-pa-st
>>>> +          - const: syscon
>>>> +
>>>> +      reg:
>>>> +        maxItems: 1
>>>> +
>>>
>>> Is this a patch in a driver series? I do not see the driver part..
>>
>> No Nishant, this is not a part of driver series. This binding patch is
>> related to [1] which is merged to net-next. The regmap will not be used
>> by drivers/soc/ti driver instead once both binding are in, the driver
>> changes will be needed in drivers/net/ethernet/ti/icssg/icssg_prueth.c
>> as there is no driver changes needed in drivers/soc/ti, I posted this
>> patch as stand alone. Considering this binding and [1] they both go to
>> different tree, I decided to get the bindings in first and in next
>> kernel cycle when they both are part of mainline linux, I can post the
>> driver changes.
> 
> This is indicating some strong coupling that is sounding a bit
> suspicious. Please add in the full series so that folks can see the
> inter dependencies.
> 

The driver changes will be needed at later point. The PA-STATS registers
dump stats related to TSN / Frame Preemption features for ICSSG drivers.
The TSN support itself is still in progress for ICSSG driver and as a
result I have not added the driver change that uses this register maps
to read / write statistics.

For your reference, I will try to explain the dependency.

The pruss node (named icssg1 in k3-am64-main.dtsi) will have below,

icssg1_pa_stats: pa-stats@2c000 {
	compatible = "ti,pruss-pa-st", "syscon";
	reg = <0x2c000 0x1000>;
};

The icssg1-eth node in k3-am642-evm will have,

icssg1_eth: icssg1-eth {

	...
	...

	ti,pa-stats = <&icssg1_pa_stats>;

	...
	...
}

Now the driver icssg_prueth.c will have the below code in it's probe,

prueth->pa_stats = syscon_regmap_lookup_by_phandle(np, "ti,pa-stats");
if (IS_ERR(prueth->pa_stats)) {
	dev_err(dev, "couldn't get ti,pa-stats syscon regmap\n");
	return -ENODEV;
}

The driver can then use regmap_read / write on prueth->pa_stats regmap
do access those registers.

This approach is similar to 'mii-rt' and 'mii-g-rt' reg maps. They have
been implemented and currently used by the icssg_prueth.c driver. You
can have a look on them for your reference.

>>
>>> if this is a memory map, why doesn't bus model work?
>>>
>>
>> I am just trying to maintain consistency here. pa-stats sub-module is
>> similar to mii-g-rt and mii-rt. I am adding pa-stats in the same way as
>> mii-g-rt and mii-rt.
>>
>> All these three modules are eventually mapping a memory region so that
>> the icssg driver can use them and read / configure registers.
> 
> Sounds like mapping a bus is more appropriate? I dont seem to see it
> though.
> 
>>
>>>
>>>>    interrupt-controller@[a-f0-9]+$:
>>>>      description: |
>>>>        PRUSS INTC Node. Each PRUSS has a single interrupt controller instance
>>>> -- 
>>>> 2.34.1
>>>>
>>>
>>
>> [1] https://lore.kernel.org/all/20240529115225.630535-1-danishanwar@ti.com/
>>
>> -- 
>> Thanks and Regards,
>> Danish
> 

-- 
Thanks and Regards,
Danish