Hi Leo,
On Fri, 5 Dec 2025 at 10:27, Leo Yan leo.yan@arm.com wrote:
On Thu, Dec 04, 2025 at 03:07:10PM +0000, Mike Leach wrote:
[...]
/** QCOM CTI does not implement Claimtag functionality as* per CoreSight specification, but its CLAIMSET register* is incorrectly initialized to 0xF. This can mislead* tools or drivers into thinking the component is claimed.** Reset CLAIMSET to 0 to reflect that no claims are active.*/writel_relaxed(0, drvdata->base + CORESIGHT_CLAIMSET);I am confused for this. If QCOM CTI does not implement claim tag, then what is the designed register at the offset CORESIGHT_CLAIMSET?
Should you bypass all claim tag related operations for QCOM CTI case? (I don't see you touch anything for claim and declaim tags).
The patch I have created to handle systems without correct claim tag operation is a dependency for this patch set. Thus no need for override here as the core code will handle this correctly.
The only issue is ensuring the non-CTI spec implementation will result in the correct detection of no claim tags present.
Your patch works only when a module has implemented claim registers.
Per the Coresight spec - unimplemented registers must be RAZ/WI- so this still works for non implemented claim registers.
QCOM CTI does not follow the spec in two aspects:
Given the patch's comment: "QCOM CTI does not implement Claim tag functionality as per CoreSight specification", I am suspect the CLAIM registers are not implemented at all in QCOM CTI.
It neither follows up the "unimplemented registers must be RAZ/WI" - the patch says its reset value is 0xF and then even can write 0 to it.
Correct - but my point is that the patch to handle lack of claim tags does work for both existent claim tags and unimplemented ones, where the spec is followed.
This leads to two issues: we end up clearing an unknown register in the CTI driver, and then the coresight core layer assumes it is reading a claim register even though it is not.
Again RAZ will simply read 0x0 - which is an indication that there are no claim bits implemented.
For QCOM CTI, combined with your patch, I would suggest directly setting csdev->access.claim_tag_impl to false (perhaps using a helper).
That would be a better solution, though as Qcom appear to have implemented a pair of standard RW registers rather than the claim tag functionality, the write solution works for this particular implementation.
If an IP violates both the rules for implemented claim registers and the rules for non-implemented claim registers, how can we rely on these registers to detect the claim feature?
My feeling is we are building a house on sand - these registers are not used for claim tags purpose at all.
No they are not, but by either writing the claim tag register with 0, or by setting the csdev->access.claim_tag_impl to false, this particular incorrect implementation instance can be made to work with the existing claim tag code.
There are effectively two issues here:-
1) The existing core code does not correctly handle insufficient claim tags or none existent claim tag register - per the coresight spec. This needs fixing for all potential components - not just this one. My claim tag patch does that.
2) This particular QCom CTI does not implement claim tags correctly. This particular instance can be made to operate correctly as detailed above as long as the core code can handle none-existent claim tags. The alternative is to bracket every claim tag access call with an "if !qcom_cti" statement. (which is what was happening in earlier patches).
We need to fix the core code anyway, and the specific QCom CTI can then be fixed in a single location without changes elsewhere in the code. This is the cleanest and least disruptive solution.
Regards
Mike
Thanks, Leo