On 23/05/18 10:21, Al Grant wrote:
I agree. The problem here is that the ETM devices are treated as AMBA devices and we rely on the AMBA bus probing (which in turn looks at the PIDs) to match a given device to ETM device.
Even if you're probing the bus you shouldn't need to look at the implementation-specific part of the id. There are generic id registers that let you progressively discover all the ETM features, all the way from generic device class right through to the fact
Al,
I think there is a bit of confusion here. The ETM driver doesn't look up the PID of the ETM for enumerating the features. Those table entries are consumed by the *amba bus* driver, which maps a given AMBA device to a driver (in this case ETM) based on the ID table passed on the amba driver. The ETM driver only uses the feature registers to identify the ETM features and it doesn't even care about the PID, once it is given a device.
The proposed patch only prints the processor name for a given ETM. It doesn't associate magic preconfigured features with an ID.
that it's an ETM 4.1 with 6 address comparators etc. You shouldn't ever need to match against a table of implementation-specific ids.
I hope that is clear. So, coming back to the forward compatibility case, a new CPU must be listed in the amba ID table for the AMBA to invoke the ETM driver for a given ETM. Thats why I mentioned about moving away from the AMBA framework and having the CPU accessible registers of ETM to detect an ETM device and then go on to use it.
Suzuki
Al
May be we need to get away from the AMBA
frame work and come up with something like the PMU probing, where we probe for the device on each CPU using the ETM feature registers and detect the devices (of course, based on the DT)
I'd think the only reason the CoreSight drivers would need to check for specific CPUs is to work around hardware errata specific to those CPUs - and in that case you would likely want to test the CPU
release/patch/stepping level in more detail.
We have a generic infrastructure in the arm64 kernel for detecting Errata, which could be leveraged to manage the coresight errata work arounds for ETMs. So we don't duplicate something just for us.
Cheers Suzuki