Hi,

On Thu, 31 Jul 2025 at 07:40, Jinlong Mao [off-list ref] wrote:

On 7/28/2025 5:52 PM, Mike Leach wrote:

quoted

Hi,

On Wed, 23 Jul 2025 at 03:58, Jinlong Mao [off-list ref] wrote:

quoted

On 7/22/2025 10:56 PM, Mike Leach wrote:

quoted

On Tue, 22 Jul 2025 at 15:07, Leo Yan [off-list ref] wrote:

quoted

On Tue, Jul 22, 2025 at 01:00:18PM +0100, Mike Leach wrote:

[...]

quoted

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

This is not permitted under the CoreSight specification as the
register mappings are different to the standard ARM CTI. Any tools
(external debug tools, userspace scripts etc.) that use the CoreSight
ID registers to identify components will fail to work on your device.

Regards

Mike

quoted

quoted

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>

-- 
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK