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

[Jinlong Mao]

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.

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>