[PATCH v3 1/2] dt-bindings: arm: Add Qualcomm extended CTI

[Jinlong Mao]

On 7/28/2025 5:52 PM, Mike Leach wrote:
> Hi,
> 
> On Wed, 23 Jul 2025 at 03:58, Jinlong Mao <quic_jinlmao at quicinc.com> wrote:
>>
>>
>>
>> On 7/22/2025 10:56 PM, Mike Leach wrote:
>>> On Tue, 22 Jul 2025 at 15:07, Leo Yan <leo.yan at arm.com> wrote:
>>>>
>>>> On Tue, Jul 22, 2025 at 01:00:18PM +0100, Mike Leach wrote:
>>>>
>>>> [...]
>>>>
>>>>> For a change of this magnitude to a CS component, that the ID
>>>>> registers will also have to change. This is a requirement of the
>>>>> Visible Component Architecture in the CoreSight specification.
>>>>> External tools cannot see the device tree.
>>>>>
>>>>> This is effectively no longer an ARM designed component, so the
>>>>> CoreSight specification requires that the DEVARCH register change to
>>>>> show qualcomm as the designer, and the architecture value change to
>>>>> represent this component.
>>>>> DEVID should be used to allow the driver to pick up parameters such as
>>>>> number of triggers as per the existing CTI component.
>>>>>
>>>>> If this component is Coresight compliant then the driver can use the
>>>>> ID registers to configure to the extended trigger architecture.
>>>>>
>>>>> With complete remapping of most of the registers, and the dropping of
>>>>> claim tag compatibility - which appears to be a breach of the
>>>>> CoreSight specification - it may be better to have a completely
>>>>> separate driver for this component.
>>>>
>>>> Good point. I'd like to confirm with the Qualcomm team: apart from the
>>>> differences in register offsets and claim bits, does this CTI module
>>>> have exactly the same bit layout and usage as CTI standard
>>>> implementation?
>>>>
>>>> If yes, then from a maintenance perspective, we probably don't want to
>>>> have two CTI drivers with identical register settings. It seems plausible
>>>> to encapsulate register access and claim logic into several functions.
>>>>
>>>>     void cti_reg_writel(u32 val, struct cti_drvdata *drvdata, bool relax);
>>>>     u32 cti_reg_readl(struct cti_drvdata *drvdata, bool relax);
>>>>     int cti_claim_device(struct cti_drvdata *drvdata);
>>>>     int cti_disclaim_device(struct cti_drvdata *drvdata, bool unlocked);
>>>>
>>>> Thanks,
>>>> Leo
>>>
>>> The CTI supports 128 triggers  - which means many more registers to
>>> enable / connect etc.
>>> I need to study the changes to determine if there are functional
>>> differences too.
>>>
>>> It might be feasible to divide the code into a common file and a pair
>>> of variants so some is reused.
>>>
>>> Mike
>> Thanks Mike & Leo & Suzuki.
>>
>> There is no register to show the version ID to distinguish between ARM
>> CTI and QCOM extended CTI.I will double confirm with internal HW team.
>>
> 
> Can you clarify here please.
> The CID0-3, PID0-7, DEVARCH and DEVTYPE registers are part of the
> CoreSight specification for component identification.
> Can you confirm they are present on your component and the values they have.
> 
> If they are present then the CoreSight specification requires that
> they be different than the standard ARM CTI.
> 
> Regards
> 
> Mike

Hi Mike,

These registers are present. I checked they are same as standard ARM
CTI. Like CIDR1(0xFF4), both are 0x90.

Thanks
Jinlong Mao

> 
>> For extended CTI, only trigger number changes and claim logic. Other
>> functions are the same as ARM CTI(bit layout of the register and usage)
>>
>> Thanks
>> Jinlong Mao>
>>
>>
> 
>