On 01/06/2023 16:59, Mike Leach wrote:
HI Suzuki,
On Thu, 25 May 2023 at 10:58, Suzuki K Poulose suzuki.poulose@arm.com wrote:
All,
This is an RFC patch to allow all ETM4 instances to be detected via AMBA driver without having to add the PIDs to the list. The AMBA driver already supports checking the DEVTYPE and DEVARCH registers for CoreSight components. This patch adds a pid,mask value that is bound to match all PIDs (with PIDR2.JEDEC field mandated to be RA0).
With this patch, we wouldn't need to add the PIDs for newer CPUs to be able to use them. An entry in the device tree is all we need. The only side effect of this patch is : If a DT description exists for an ETM and the CPU ETM has an erratum, the driver may still probe it and use it. But then the DT shouldn't have described it in the first place.
Don't think this is an issue.
In the previous mechanism, with an ETM with an erratum - or indeed need of some arch specific extension as we allow now - someone would have added the PID - tested it, hit the erratum, and would have to investigate and fix according to what is required. This changes nothing in terms of handling errata on ETM hardware - it just removes the add PID step.
For new ETM that work out of the box, this saves time re-spinning the driver every time - which is kind of what we want from device tree!
I'd go for it.
Moreover, the same principle could be added to the CTI drivers - though these are generally pretty standard anyway (i.e. based on Coresight Soc 600/400), so may be no pressing need for this right now.
Thank you Mike, I will send it as a proper patch.
Cheers Suzuki