[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201114051715.GA23685@codeaurora.org>
Date: Sat, 14 Nov 2020 13:17:15 +0800
From: Tingwei Zhang <tingweiz@...eaurora.org>
To: Anshuman Khandual <anshuman.khandual@....com>
Cc: linux-arm-kernel@...ts.infradead.org, coresight@...ts.linaro.org,
mike.leach@...aro.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC 00/11] arm64: coresight: Enable ETE and TRBE
Hi Anshuman,
On Tue, Nov 10, 2020 at 08:44:58PM +0800, Anshuman Khandual wrote:
> This series enables future IP trace features Embedded Trace Extension (ETE)
> and Trace Buffer Extension (TRBE). This series depends on the ETM system
> register instruction support series [0] and the v8.4 Self hosted tracing
> support series (Jonathan Zhou) [1]. The tree is available here [2] for
> quick access.
>
> ETE is the PE (CPU) trace unit for CPUs, implementing future architecture
> extensions. ETE overlaps with the ETMv4 architecture, with additions to
> support the newer architecture features and some restrictions on the
> supported features w.r.t ETMv4. The ETE support is added by extending the
> ETMv4 driver to recognise the ETE and handle the features as exposed by the
> TRCIDRx registers. ETE only supports system instructions access from the
> host CPU. The ETE could be integrated with a TRBE (see below), or with the
> legacy CoreSight trace bus (e.g, ETRs). Thus the ETE follows same firmware
> description as the ETMs and requires a node per instance.
>
> Trace Buffer Extensions (TRBE) implements a per CPU trace buffer, which is
> accessible via the system registers and can be combined with the ETE to
> provide a 1x1 configuration of source & sink. TRBE is being represented
> here as a CoreSight sink. Primary reason is that the ETE source could work
> with other traditional CoreSight sink devices. As TRBE captures the trace
> data which is produced by ETE, it cannot work alone.
>
> TRBE representation here have some distinct deviations from a traditional
> CoreSight sink device. Coresight path between ETE and TRBE are not built
> during boot looking at respective DT or ACPI entries. Instead TRBE gets
> checked on each available CPU, when found gets connected with respective
> ETE source device on the same CPU, after altering its outward connections.
> ETE TRBE path connection lasts only till the CPU is online. But ETE-TRBE
> coupling/decoupling method implemented here is not optimal and would be
> reworked later on.
Only perf mode is supported in TRBE in current path. Will you consider
support sysfs mode as well in following patch sets?
Thanks,
Tingwei
>
> Unlike traditional sinks, TRBE can generate interrupts to signal including
> many other things, buffer got filled. The interrupt is a PPI and should be
> communicated from the platform. DT or ACPI entry representing TRBE should
> have the PPI number for a given platform. During perf session, the TRBE IRQ
> handler should capture trace for perf auxiliary buffer before restarting it
> back. System registers being used here to configure ETE and TRBE could be
> referred in the link below.
>
> https://developer.arm.com/docs/ddi0601/g/aarch64-system-registers.
>
> This adds another change where CoreSight sink device needs to be disabled
> before capturing the trace data for perf in order to avoid race condition
> with another simultaneous TRBE IRQ handling. This might cause problem with
> traditional sink devices which can be operated in both sysfs and perf mode.
> This needs to be addressed correctly. One option would be to move the
> update_buffer callback into the respective sink devices. e.g, disable().
>
> This series is primarily looking from some early feed back both on proposed
> design and its implementation. It acknowledges, that it might be incomplete
> and will have scopes for improvement.
>
> Things todo:
> - Improve ETE-TRBE coupling and decoupling method
> - Improve TRBE IRQ handling for all possible corner cases
> - Implement sysfs based trace sessions
>
> [0]
> https://lore.kernel.org/linux-arm-kernel/20201028220945.3826358-1-suzuki.poulose@arm.com/
> [1]
> https://lore.kernel.org/linux-arm-kernel/1600396210-54196-1-git-send-email-jonathan.zhouwen@huawei.com/
> [2]
> https://gitlab.arm.com/linux-arm/linux-skp/-/tree/coresight/etm/v8.4-self-hosted
>
> Anshuman Khandual (6):
> arm64: Add TRBE definitions
> coresight: sink: Add TRBE driver
> coresight: etm-perf: Truncate the perf record if handle has no space
> coresight: etm-perf: Disable the path before capturing the trace data
> coresgith: etm-perf: Connect TRBE sink with ETE source
> dts: bindings: Document device tree binding for Arm TRBE
>
> Suzuki K Poulose (5):
> coresight: etm-perf: Allow an event to use different sinks
> coresight: Do not scan for graph if none is present
> coresight: etm4x: Add support for PE OS lock
> coresight: ete: Add support for sysreg support
> coresight: ete: Detect ETE as one of the supported ETMs
>
> .../devicetree/bindings/arm/coresight.txt | 3 +
> Documentation/devicetree/bindings/arm/trbe.txt | 20 +
> Documentation/trace/coresight/coresight-trbe.rst | 36 +
> arch/arm64/include/asm/sysreg.h | 51 ++
> drivers/hwtracing/coresight/Kconfig | 11 +
> drivers/hwtracing/coresight/Makefile | 1 +
> drivers/hwtracing/coresight/coresight-etm-perf.c | 85 ++-
> drivers/hwtracing/coresight/coresight-etm-perf.h | 4 +
> drivers/hwtracing/coresight/coresight-etm4x-core.c | 144 +++-
> drivers/hwtracing/coresight/coresight-etm4x.h | 64 +-
> drivers/hwtracing/coresight/coresight-platform.c | 9 +-
> drivers/hwtracing/coresight/coresight-trbe.c | 768
> +++++++++++++++++++++
> drivers/hwtracing/coresight/coresight-trbe.h | 525 ++++++++++++++
> include/linux/coresight.h | 2 +
> 14 files changed, 1680 insertions(+), 43 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/trbe.txt
> create mode 100644 Documentation/trace/coresight/coresight-trbe.rst
> create mode 100644 drivers/hwtracing/coresight/coresight-trbe.c
> create mode 100644 drivers/hwtracing/coresight/coresight-trbe.h
>
> --
> 2.7.4
>
> _______________________________________________
> CoreSight mailing list
> CoreSight@...ts.linaro.org
> https://lists.linaro.org/mailman/listinfo/coresight
Powered by blists - more mailing lists