CSAL vs Coresight driver in kernel

[bj-wanghz]

In Linux kernel/drivers/hwtracing/coresight, there are drivers for some CS components, such as ETM, STM. We can use sysfs to access these compoents in user space. So what's the advantage of CSAL compared to kernel drivers when used on Linux platform except that CSAL supports some components which kernel doesn't (ELA for example)?

[algrant-arm]

That's basically the only advantage. If you can get the job done with kernel drivers, through sysfs or perf_event_open(), it's generally best to do that.

CSAL should generally not be used on a production Linux system if you plan to also use the kernel drivers, otherwise you may run into problems with clashing ATB trace ids, devices left in inconsistent states etc.

There are a few main reasons for using CSAL (via /dev/mem) under Linux:

• access devices which the kernel doesn't (yet) support, or in configurations that the kernel doesn't support. For example, experimenting with complex configurations of the ETM, before Mike Leach's new "custom configurations" feature lands in the kernel.
• simply for convenience. If you're planning to use CSAL in more constrained, firmware type of environment (e.g. for on-board diagnostics), it might be useful to develop the code first under Linux. CSAL's "devmemd" feature may be useful here.