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