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

Leo Yan leo.yan at arm.com
Tue Jul 22 07:06:59 PDT 2025


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



More information about the linux-arm-kernel mailing list