Hi Leo,
-----Original Message----- From: Leo Yan leo.yan@linaro.org Sent: Wednesday, April 24, 2019 4:15 PM To: Wojciech Żmuda wzmuda@n7space.com Cc: coresight@lists.linaro.org Subject: Re: [RFC PATCH v1] perf test: Introduce script for Arm CoreSight testing
Hi Wojciech,
On Wed, Apr 24, 2019 at 12:25:21PM +0000, Wojciech Żmuda wrote:
Hi Leo,
I ran your script on a Zynq Ultrascale+ devboard with 'perf test ...'
and it succeeded.
Thanks a lot for testing!
After examining the source code, I came up with the following questions:
- What about other sinks? For now I see it is hardcoded to look for
sysfs devices with *.etr only.
For example, Zynq US+ has one TMC-ETR and two TMC-ETFs - shouldn't ETFs
be tested as well?
Yes, actually I have considered this question when I wrote the script.
From my understanding, ETR is located after ETF in the trace data path and it's more complex than ETF. So if we test ETR successfully, usually means the ETF in the middle of trace path also has been (works as LINKSINK type).
This is actually how CoreSight in Zynq US+ is wired. I asked because I wasn't sure if this is a common design, that ETR is always preceded by ETF. If this is how CoreSight topology looks like in every SoC, then I agree that testing only ETRs sounds reasonable.
Another thing I noted that on several platforms (Juno, Hikey/Hikey960, DB410c), all of them only has single one ETR component, so means this testing is valid on these platforms. But ETF usage is quite diverse on different platforms, e.g. as a special case, on Juno board, one ETF even cannot create any trace path [1] so it will always fail if we use perf with it.
That's interesting. What is the purpose of such ETF? LINKSINK mode only?
Thanks, Wojciech
- Is there any sink naming convention? AFAIR sysfs file names depend
on what's in DTS. I can imagine a situation where I have two ETRs with nodes names etr1@88f00f00, etr2@88f00f80 - the script will not discover them. I took a brief look at the bindings document and I don't
see any obvious remarks on how should we name DTS nodes.
Good point. I will change the code as below:
arm_cs_etr_test() {
for i in /sys/bus/coresight/devices/*.etr; do
for i in /sys/bus/coresight/devices/*.etr*; doJust want to remind (but maybe this is off topic), ePAPR [2] suggests to use node name as general as possible, so the ETR will use 'etr@xxxxxxxx' as device node name in dts, and in theory we should always use the unified format for ETR node; anyway, will change the code with more flexible match.
Sorry if I confused something here, but perhaps this is the right moment to establish such convention?
Not at all. Thanks a lot for reviewing and suggestions!
Thanks, Leo Yan
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/ar ch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi?h=v5.1-rc6#n26 [2] https://elinux.org/images/c/cf/Power_ePAPR_APPROVED_v1.1.pdf