From: Yingchao Deng <quic_yingdeng@quicinc.com>
Add Qualcomm extended CTI support in CTI binding file. Qualcomm
extended CTI supports up to 128 triggers.
Signed-off-by: Yingchao Deng <quic_yingdeng@quicinc.com>
Signed-off-by: Mao Jinlong <quic_jinlmao@quicinc.com>
---
Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml
index 2d5545a2b49c..1aa27461f5bc 100644
--- a/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml
+++ b/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml
@@ -84,7 +84,9 @@ properties:
- const: arm,coresight-cti
- const: arm,primecell
- items:
- - const: arm,coresight-cti-v8-arch
+ - enum:
+ - arm,coresight-cti-v8-arch
+ - qcom,coresight-cti-extended
- const: arm,coresight-cti
- const: arm,primecell
--
2.25.1On 22/07/2025 09:14, Mao Jinlong wrote: > From: Yingchao Deng <quic_yingdeng@quicinc.com> > > Add Qualcomm extended CTI support in CTI binding file. Qualcomm > extended CTI supports up to 128 triggers. > > Signed-off-by: Yingchao Deng <quic_yingdeng@quicinc.com> > Signed-off-by: Mao Jinlong <quic_jinlmao@quicinc.com> > --- > Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml > index 2d5545a2b49c..1aa27461f5bc 100644 > --- a/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml > +++ b/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml > @@ -84,7 +84,9 @@ properties: > - const: arm,coresight-cti > - const: arm,primecell > - items: > - - const: arm,coresight-cti-v8-arch > + - enum: > + - arm,coresight-cti-v8-arch > + - qcom,coresight-cti-extended Why not call it qcom,coresight-cti ? There are no other "qcom,coresight-cti", so "extended" is not required. Is this specific to CPU (i.e., CPU bound) ? Suzuki > - const: arm,coresight-cti > - const: arm,primecell >
On Tue, Jul 22, 2025 at 09:49:28AM +0100, Suzuki Kuruppassery Poulose wrote: > On 22/07/2025 09:14, Mao Jinlong wrote: > > From: Yingchao Deng <quic_yingdeng@quicinc.com> > > > > Add Qualcomm extended CTI support in CTI binding file. Qualcomm > > extended CTI supports up to 128 triggers. > > > > Signed-off-by: Yingchao Deng <quic_yingdeng@quicinc.com> > > Signed-off-by: Mao Jinlong <quic_jinlmao@quicinc.com> > > --- > > Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml > > index 2d5545a2b49c..1aa27461f5bc 100644 > > --- a/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml > > +++ b/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml > > @@ -84,7 +84,9 @@ properties: > > - const: arm,coresight-cti > > - const: arm,primecell > > - items: > > - - const: arm,coresight-cti-v8-arch > > + - enum: > > + - arm,coresight-cti-v8-arch > > + - qcom,coresight-cti-extended > > Why not call it qcom,coresight-cti ? > > There are no other "qcom,coresight-cti", so "extended" is not required. > Is this specific to CPU (i.e., CPU bound) ? I roughly went through the second path. Combining two patches in this series, I am wandering if can directly check registers (e.g. PID/CID) to find CTI with qcom extension. If so, you do not need an extra DT binding, right? Thanks, Leo > Suzuki > > > - const: arm,coresight-cti > > - const: arm,primecell > > _______________________________________________ > CoreSight mailing list -- coresight@lists.linaro.org > To unsubscribe send an email to coresight-leave@lists.linaro.org
Hi On Tue, 22 Jul 2025 at 10:14, Leo Yan <leo.yan@arm.com> wrote: > > On Tue, Jul 22, 2025 at 09:49:28AM +0100, Suzuki Kuruppassery Poulose wrote: > > On 22/07/2025 09:14, Mao Jinlong wrote: > > > From: Yingchao Deng <quic_yingdeng@quicinc.com> > > > > > > Add Qualcomm extended CTI support in CTI binding file. Qualcomm > > > extended CTI supports up to 128 triggers. > > > > > > Signed-off-by: Yingchao Deng <quic_yingdeng@quicinc.com> > > > Signed-off-by: Mao Jinlong <quic_jinlmao@quicinc.com> > > > --- > > > Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml | 4 +++- > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml > > > index 2d5545a2b49c..1aa27461f5bc 100644 > > > --- a/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml > > > +++ b/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml > > > @@ -84,7 +84,9 @@ properties: > > > - const: arm,coresight-cti > > > - const: arm,primecell > > > - items: > > > - - const: arm,coresight-cti-v8-arch > > > + - enum: > > > + - arm,coresight-cti-v8-arch > > > + - qcom,coresight-cti-extended > > > > Why not call it qcom,coresight-cti ? > > > > There are no other "qcom,coresight-cti", so "extended" is not required. > > Is this specific to CPU (i.e., CPU bound) ? > > I roughly went through the second path. Combining two patches in this > series, I am wandering if can directly check registers (e.g. PID/CID) > to find CTI with qcom extension. If so, you do not need an extra DT > binding, right? > > Thanks, > Leo > > > Suzuki > > > > > - const: arm,coresight-cti > > > - const: arm,primecell > > > > _______________________________________________ > > CoreSight mailing list -- coresight@lists.linaro.org > > To unsubscribe send an email to coresight-leave@lists.linaro.org 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. Regards Mike -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK
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
On Tue, 22 Jul 2025 at 15:07, Leo Yan <leo.yan@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 -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK
On 7/22/2025 10:56 PM, Mike Leach wrote: > On Tue, 22 Jul 2025 at 15:07, Leo Yan <leo.yan@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>
Hi, On Wed, 23 Jul 2025 at 03:58, Jinlong Mao <quic_jinlmao@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@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 > 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
On 7/28/2025 5:52 PM, Mike Leach wrote: > Hi, > > On Wed, 23 Jul 2025 at 03:58, Jinlong Mao <quic_jinlmao@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@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> >> >> > >
Hi, On Thu, 31 Jul 2025 at 07:40, Jinlong Mao <quic_jinlmao@quicinc.com> wrote: > > > > On 7/28/2025 5:52 PM, Mike Leach wrote: > > Hi, > > > > On Wed, 23 Jul 2025 at 03:58, Jinlong Mao <quic_jinlmao@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@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 > 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 > > > >> 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
© 2016 - 2025 Red Hat, Inc.