Hi Suzuki,
On Fri, 11 Jan 2019 at 13:25, Suzuki K Poulose suzuki.poulose@arm.com wrote:
Hi Mike,
On 09/01/2019 22:54, Mike Leach wrote:
Adds in code to the CoreSight core to prepare for the addition of the CTI driver.
Adds functionality to add cross reference association between CTI and other CoreSight devices.
Adds functionality to enable associated CTI when CoreSight devices are enabled by the trace path code.
Signed-off-by: Mike Leach mike.leach@linaro.org
drivers/hwtracing/coresight/coresight.c | 51 ++++++++++++++++++++++++- 1 file changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c index 2b0df1a0a8df..01ad708ca7a7 100644 --- a/drivers/hwtracing/coresight/coresight.c +++ b/drivers/hwtracing/coresight/coresight.c @@ -214,6 +214,36 @@ void coresight_disclaim_device(void __iomem *base) CS_LOCK(base); }
+/* enable or disable an associated CTI device of the supplied CS device */ +static void +coresight_control_assoc_ectdev(struct coresight_device *csdev, int enable) +{
int ect_ret = 0;
struct coresight_device *ect_csdev = csdev->ect_dev;
if (!ect_csdev)
return;
if (enable) {
if (ect_ops(ect_csdev)->enable)
ect_ret = ect_ops(ect_csdev)->enable(ect_csdev, NULL);
} else {
if (ect_ops(ect_csdev)->disable)
ect_ret = ect_ops(ect_csdev)->disable(ect_csdev, NULL);
}
dev_info(&csdev->dev, "%s assoc CTI %s for %s\n",
enable ? "Enabling" : "Disabling",
dev_name(&ect_csdev->dev), dev_name(&csdev->dev));
/* even if the control failed - we don't want to fail possible trace
* capture.
*/
if (ect_ret)
dev_info(&csdev->dev, "Associated ECT device (%s) %s failed\n",
dev_name(&ect_csdev->dev), enable ? "enable" : "disable");
+}
As I mentioned in the previous patch, if you make this a subtype of helper device, this should all be done automatically if it is "connected" to any of the devices that appear in the path, which I think is the way to go.
Thoughts ? Suzuki
The CTI connection nodes as I am defining them, declare both an associated device and the set of signals going to and from the device. The signals are declared on a per connection basis as they are implementation dependent (other than v8 core CTIs where the interconnection is architecturally set). The devicetree declarations allow this specific hardware signal setup to be captured by the driver and interrogated via the driver API.
Now, CTIs can connect to multiple other CS devices, a CPU, other hardware, or simply run IO signals off the board to no device at all. The current CoreSight standard associates ETM and CPU with a simple phandle reference. The description of connections along the trace data path from ETM source to sink (including the helper devices) use the in-ports / out-ports / endpoints declarations with matching expected on both connected components. I tried using the helper paradigm with the CTI but eventually went in another direction as:-
1) We would have had to declare endpoints on the CPUs in order to get a valid connection - there is no precedent for this in the current device tree definitions. 2) It is possible and valid to create a CTI device with no associated registered component. this is for IO only or exploration of the system where the full connection information is not known. 3) I was concerned about the massive increase in DTS declarations for a single CS component - in Juno on of the CTIs connects to four separate devices. That would be 8 endpoints on the CTI, (one in and out per device x 4 devices) and 2 ep per device. There are 16 CTIs on the DB410 (though we only have details for 6 of these at present). 4) there is no linear path for CTI connectivity - the star topology via the CTM allows complete inter-connectivity - dependent on device programming. I felt this justified a separate class of device.
Therefore I chose to create a devicetree model that followed the CPU / ETM method of phandle reference for all associations - giving a consistent connection declaration methodology for all the connections, irrespective of the type of associated device (or lack thereof). The CTI could still be a sub-type of helper I guess, but the code is still needed to enable alongside the trace data path.
The goal was to create a set of declarations that was flexible enough to be equally used even where the CTI information was lacking. I also wanted something that was relatively easy to add to the devicetree and easy to maintain.
Regards
Mike