From patchwork Thu Dec 21 08:20:10 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leo Yan X-Patchwork-Id: 122514 Delivered-To: patch@linaro.org Received: by 10.140.22.227 with SMTP id 90csp580339qgn; Thu, 21 Dec 2017 00:20:55 -0800 (PST) X-Google-Smtp-Source: ACJfBovmEB/1PS8aNgz/+f+gv8jxFiOX1mlo29jl2yT352Y1dwp3tikg24mRog5zn0aEyCvRJjdR X-Received: by 10.84.194.163 with SMTP id h32mr9462304pld.335.1513844455160; Thu, 21 Dec 2017 00:20:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1513844455; cv=none; d=google.com; s=arc-20160816; b=lN1Ug3s8R2WGeHg+4pq9ViGiOXgyM2RUreJIbczW51z2AYDg+jBnxwTMXIX/5ytok+ Pb9QHXN0oeG4aEfHt+DENRv2ajelKok1FMoE8rAcp52ZX4J+wyX+tk4TyFu6bnj0phuV CpTrphOHYHl2oT+rgSu7tQuYL+65YFkLh32yU+JdRPGVRcA3/6QpP8hX+gFOi/tQ37P0 897DqRzfZgzt9nmh5g625aj5ODVYDc+kwtJ7c+TsAIQWC4FF315RCplG/k9E8PdiXPuY bbsoMwdCC/uYHqZi1Fs1grBBORUI7kLOKjkab4O4OZLlLfhmQRFATUcp+Z785rLckexC OwRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=gXXPWMGNxZULlMcAHzq686TRUkauCxvuGvP6g9sg5gg=; b=fu/HMvA71uxtDCvSP8jGIGlxJ/yzvtH7NNRxpoUZ4gV2QnawqU3Z89pTjwrADxFtKC omO2u4QpSzzi6i7IpvFAllP+iYCvWj9d6QSDwviK0gIcBMD5Q9R0ixI4TlsrpIzSbYJf /kYUGEqQajwlU5Uhy+F1LRs3dBkr/2LcRZfQRCKRvEX0SUV1uG5AEFdTxTzswpscLRwm 0ToOQm8E8xjXWXh6LVMnyurnBHIUXsTxPTjXtM+1WN/quhUNa/Ou3AxBg+jEx/vuRcJa cK9oHaimna5iQ1OId9qTyEx/eWoMcZYbjD0ej+vGyR+efqXK15iPueGpuNBWMx3h9Ni7 vFJA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=esJXm4Va; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n10si14214966plk.422.2017.12.21.00.20.54; Thu, 21 Dec 2017 00:20:55 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=esJXm4Va; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751675AbdLUIUv (ORCPT + 28 others); Thu, 21 Dec 2017 03:20:51 -0500 Received: from mail-pf0-f196.google.com ([209.85.192.196]:39536 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751328AbdLUIUo (ORCPT ); Thu, 21 Dec 2017 03:20:44 -0500 Received: by mail-pf0-f196.google.com with SMTP id l24so13682577pfj.6 for ; Thu, 21 Dec 2017 00:20:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=gXXPWMGNxZULlMcAHzq686TRUkauCxvuGvP6g9sg5gg=; b=esJXm4Va7bLzoWY9L2z2qwnczVxeUT3gnxZKw0sn2FNf7OzeLKBs/qgHYz1ep5tEI+ B4ocvxFE10RPCfmgKkSIqTb1c/NT7Mo1MuBxRGJ1NaB447JUdGvJfZ1XKc8uAEudrO3n gNHpiewpj/wMnQbrcdAjdYXFVBu9bb8a4xAJI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=gXXPWMGNxZULlMcAHzq686TRUkauCxvuGvP6g9sg5gg=; b=H6jqkzMenAG/QgRaSxLEyJ3gLd9erDEoJgrVuZ5zfXvTqycCqQZQWtND4Riw0NohZj 26N8AT1Gf55nnah7PnuGECbVrab16D1FeHSs8wGzPepjdW2UE34FJKGjI0h53CanNs7I nU2ZMK7+UnPtvNn8jpyCeKzh8N/srVfTlZx8H+kUSmgNsKWQ884dd/9OnfvlO7ogPaSw gWl4xftNEVLQGiTLbnP56+rTw8KzDCIz7yT6Y5DUGlV8bvTXCLlDvS0q7VpuiXfqKaHC QvJsi9nAjhc109iVTamp758wZWmfGNMPz4p37cuqlPbFUXehgJ7UvJIvAtYS3yxqP9AE Qe/Q== X-Gm-Message-State: AKGB3mJMv8N/WI7EAz19C9ABsmC/pWUK/lo8atuCdUOKHGKFtdoFleUw Ek7vwbesMrrDSvrmF4HWVBM85g== X-Received: by 10.99.112.89 with SMTP id a25mr7848292pgn.431.1513844443249; Thu, 21 Dec 2017 00:20:43 -0800 (PST) Received: from localhost.localdomain (li159-223.members.linode.com. [173.230.149.223]) by smtp.gmail.com with ESMTPSA id r86sm43699720pfk.114.2017.12.21.00.20.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Dec 2017 00:20:42 -0800 (PST) From: Leo Yan To: Jonathan Corbet , Mathieu Poirier , Greg Kroah-Hartman , Will Deacon , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, coresight@lists.linaro.org Cc: Leo Yan Subject: [PATCH v3 1/6] doc: Add Coresight documentation directory Date: Thu, 21 Dec 2017 16:20:10 +0800 Message-Id: <1513844415-11427-2-git-send-email-leo.yan@linaro.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1513844415-11427-1-git-send-email-leo.yan@linaro.org> References: <1513844415-11427-1-git-send-email-leo.yan@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org For easily management and friendly adding more Coresight related documentations, this commit creates one dedicated directory: Documentation/trace/coresight. It moves Coresight related docs into this new directory and updates MAINTAINERS file to reflect docs movement. Signed-off-by: Leo Yan --- Documentation/trace/coresight-cpu-debug.txt | 187 ------------ Documentation/trace/coresight.txt | 332 --------------------- .../trace/coresight/coresight-cpu-debug.txt | 187 ++++++++++++ Documentation/trace/coresight/coresight.txt | 332 +++++++++++++++++++++ MAINTAINERS | 4 +- 5 files changed, 521 insertions(+), 521 deletions(-) delete mode 100644 Documentation/trace/coresight-cpu-debug.txt delete mode 100644 Documentation/trace/coresight.txt create mode 100644 Documentation/trace/coresight/coresight-cpu-debug.txt create mode 100644 Documentation/trace/coresight/coresight.txt -- 2.7.4 diff --git a/Documentation/trace/coresight-cpu-debug.txt b/Documentation/trace/coresight-cpu-debug.txt deleted file mode 100644 index 2b9b51c..0000000 --- a/Documentation/trace/coresight-cpu-debug.txt +++ /dev/null @@ -1,187 +0,0 @@ - Coresight CPU Debug Module - ========================== - - Author: Leo Yan - Date: April 5th, 2017 - -Introduction ------------- - -Coresight CPU debug module is defined in ARMv8-a architecture reference manual -(ARM DDI 0487A.k) Chapter 'Part H: External debug', the CPU can integrate -debug module and it is mainly used for two modes: self-hosted debug and -external debug. Usually the external debug mode is well known as the external -debugger connects with SoC from JTAG port; on the other hand the program can -explore debugging method which rely on self-hosted debug mode, this document -is to focus on this part. - -The debug module provides sample-based profiling extension, which can be used -to sample CPU program counter, secure state and exception level, etc; usually -every CPU has one dedicated debug module to be connected. Based on self-hosted -debug mechanism, Linux kernel can access these related registers from mmio -region when the kernel panic happens. The callback notifier for kernel panic -will dump related registers for every CPU; finally this is good for assistant -analysis for panic. - - -Implementation --------------- - -- During driver registration, it uses EDDEVID and EDDEVID1 - two device ID - registers to decide if sample-based profiling is implemented or not. On some - platforms this hardware feature is fully or partially implemented; and if - this feature is not supported then registration will fail. - -- At the time this documentation was written, the debug driver mainly relies on - information gathered by the kernel panic callback notifier from three - sampling registers: EDPCSR, EDVIDSR and EDCIDSR: from EDPCSR we can get - program counter; EDVIDSR has information for secure state, exception level, - bit width, etc; EDCIDSR is context ID value which contains the sampled value - of CONTEXTIDR_EL1. - -- The driver supports a CPU running in either AArch64 or AArch32 mode. The - registers naming convention is a bit different between them, AArch64 uses - 'ED' for register prefix (ARM DDI 0487A.k, chapter H9.1) and AArch32 uses - 'DBG' as prefix (ARM DDI 0487A.k, chapter G5.1). The driver is unified to - use AArch64 naming convention. - -- ARMv8-a (ARM DDI 0487A.k) and ARMv7-a (ARM DDI 0406C.b) have different - register bits definition. So the driver consolidates two difference: - - If PCSROffset=0b0000, on ARMv8-a the feature of EDPCSR is not implemented; - but ARMv7-a defines "PCSR samples are offset by a value that depends on the - instruction set state". For ARMv7-a, the driver checks furthermore if CPU - runs with ARM or thumb instruction set and calibrate PCSR value, the - detailed description for offset is in ARMv7-a ARM (ARM DDI 0406C.b) chapter - C11.11.34 "DBGPCSR, Program Counter Sampling Register". - - If PCSROffset=0b0010, ARMv8-a defines "EDPCSR implemented, and samples have - no offset applied and do not sample the instruction set state in AArch32 - state". So on ARMv8 if EDDEVID1.PCSROffset is 0b0010 and the CPU operates - in AArch32 state, EDPCSR is not sampled; when the CPU operates in AArch64 - state EDPCSR is sampled and no offset are applied. - - -Clock and power domain ----------------------- - -Before accessing debug registers, we should ensure the clock and power domain -have been enabled properly. In ARMv8-a ARM (ARM DDI 0487A.k) chapter 'H9.1 -Debug registers', the debug registers are spread into two domains: the debug -domain and the CPU domain. - - +---------------+ - | | - | | - +----------+--+ | - dbg_clock -->| |**| |<-- cpu_clock - | Debug |**| CPU | - dbg_power_domain -->| |**| |<-- cpu_power_domain - +----------+--+ | - | | - | | - +---------------+ - -For debug domain, the user uses DT binding "clocks" and "power-domains" to -specify the corresponding clock source and power supply for the debug logic. -The driver calls the pm_runtime_{put|get} operations as needed to handle the -debug power domain. - -For CPU domain, the different SoC designs have different power management -schemes and finally this heavily impacts external debug module. So we can -divide into below cases: - -- On systems with a sane power controller which can behave correctly with - respect to CPU power domain, the CPU power domain can be controlled by - register EDPRCR in driver. The driver firstly writes bit EDPRCR.COREPURQ - to power up the CPU, and then writes bit EDPRCR.CORENPDRQ for emulation - of CPU power down. As result, this can ensure the CPU power domain is - powered on properly during the period when access debug related registers; - -- Some designs will power down an entire cluster if all CPUs on the cluster - are powered down - including the parts of the debug registers that should - remain powered in the debug power domain. The bits in EDPRCR are not - respected in these cases, so these designs do not support debug over - power down in the way that the CoreSight / Debug designers anticipated. - This means that even checking EDPRSR has the potential to cause a bus hang - if the target register is unpowered. - - In this case, accessing to the debug registers while they are not powered - is a recipe for disaster; so we need preventing CPU low power states at boot - time or when user enable module at the run time. Please see chapter - "How to use the module" for detailed usage info for this. - - -Device Tree Bindings --------------------- - -See Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt for details. - - -How to use the module ---------------------- - -If you want to enable debugging functionality at boot time, you can add -"coresight_cpu_debug.enable=1" to the kernel command line parameter. - -The driver also can work as module, so can enable the debugging when insmod -module: -# insmod coresight_cpu_debug.ko debug=1 - -When boot time or insmod module you have not enabled the debugging, the driver -uses the debugfs file system to provide a knob to dynamically enable or disable -debugging: - -To enable it, write a '1' into /sys/kernel/debug/coresight_cpu_debug/enable: -# echo 1 > /sys/kernel/debug/coresight_cpu_debug/enable - -To disable it, write a '0' into /sys/kernel/debug/coresight_cpu_debug/enable: -# echo 0 > /sys/kernel/debug/coresight_cpu_debug/enable - -As explained in chapter "Clock and power domain", if you are working on one -platform which has idle states to power off debug logic and the power -controller cannot work well for the request from EDPRCR, then you should -firstly constraint CPU idle states before enable CPU debugging feature; so can -ensure the accessing to debug logic. - -If you want to limit idle states at boot time, you can use "nohlt" or -"cpuidle.off=1" in the kernel command line. - -At the runtime you can disable idle states with below methods: - -It is possible to disable CPU idle states by way of the PM QoS -subsystem, more specifically by using the "/dev/cpu_dma_latency" -interface (see Documentation/power/pm_qos_interface.txt for more -details). As specified in the PM QoS documentation the requested -parameter will stay in effect until the file descriptor is released. -For example: - -# exec 3<> /dev/cpu_dma_latency; echo 0 >&3 -... -Do some work... -... -# exec 3<>- - -The same can also be done from an application program. - -Disable specific CPU's specific idle state from cpuidle sysfs (see -Documentation/cpuidle/sysfs.txt): -# echo 1 > /sys/devices/system/cpu/cpu$cpu/cpuidle/state$state/disable - - -Output format -------------- - -Here is an example of the debugging output format: - -ARM external debug module: -coresight-cpu-debug 850000.debug: CPU[0]: -coresight-cpu-debug 850000.debug: EDPRSR: 00000001 (Power:On DLK:Unlock) -coresight-cpu-debug 850000.debug: EDPCSR: [] handle_IPI+0x174/0x1d8 -coresight-cpu-debug 850000.debug: EDCIDSR: 00000000 -coresight-cpu-debug 850000.debug: EDVIDSR: 90000000 (State:Non-secure Mode:EL1/0 Width:64bits VMID:0) -coresight-cpu-debug 852000.debug: CPU[1]: -coresight-cpu-debug 852000.debug: EDPRSR: 00000001 (Power:On DLK:Unlock) -coresight-cpu-debug 852000.debug: EDPCSR: [] debug_notifier_call+0x23c/0x358 -coresight-cpu-debug 852000.debug: EDCIDSR: 00000000 -coresight-cpu-debug 852000.debug: EDVIDSR: 90000000 (State:Non-secure Mode:EL1/0 Width:64bits VMID:0) diff --git a/Documentation/trace/coresight.txt b/Documentation/trace/coresight.txt deleted file mode 100644 index a33c88c..0000000 --- a/Documentation/trace/coresight.txt +++ /dev/null @@ -1,332 +0,0 @@ - Coresight - HW Assisted Tracing on ARM - ====================================== - - Author: Mathieu Poirier - Date: September 11th, 2014 - -Introduction ------------- - -Coresight is an umbrella of technologies allowing for the debugging of ARM -based SoC. It includes solutions for JTAG and HW assisted tracing. This -document is concerned with the latter. - -HW assisted tracing is becoming increasingly useful when dealing with systems -that have many SoCs and other components like GPU and DMA engines. ARM has -developed a HW assisted tracing solution by means of different components, each -being added to a design at synthesis time to cater to specific tracing needs. -Components are generally categorised as source, link and sinks and are -(usually) discovered using the AMBA bus. - -"Sources" generate a compressed stream representing the processor instruction -path based on tracing scenarios as configured by users. From there the stream -flows through the coresight system (via ATB bus) using links that are connecting -the emanating source to a sink(s). Sinks serve as endpoints to the coresight -implementation, either storing the compressed stream in a memory buffer or -creating an interface to the outside world where data can be transferred to a -host without fear of filling up the onboard coresight memory buffer. - -At typical coresight system would look like this: - - ***************************************************************** - **************************** AMBA AXI ****************************===|| - ***************************************************************** || - ^ ^ | || - | | * ** - 0000000 ::::: 0000000 ::::: ::::: @@@@@@@ |||||||||||| - 0 CPU 0<-->: C : 0 CPU 0<-->: C : : C : @ STM @ || System || - |->0000000 : T : |->0000000 : T : : T :<--->@@@@@ || Memory || - | #######<-->: I : | #######<-->: I : : I : @@@<-| |||||||||||| - | # ETM # ::::: | # PTM # ::::: ::::: @ | - | ##### ^ ^ | ##### ^ ! ^ ! . | ||||||||| - | |->### | ! | |->### | ! | ! . | || DAP || - | | # | ! | | # | ! | ! . | ||||||||| - | | . | ! | | . | ! | ! . | | | - | | . | ! | | . | ! | ! . | | * - | | . | ! | | . | ! | ! . | | SWD/ - | | . | ! | | . | ! | ! . | | JTAG - *****************************************************************<-| - *************************** AMBA Debug APB ************************ - ***************************************************************** - | . ! . ! ! . | - | . * . * * . | - ***************************************************************** - ******************** Cross Trigger Matrix (CTM) ******************* - ***************************************************************** - | . ^ . . | - | * ! * * | - ***************************************************************** - ****************** AMBA Advanced Trace Bus (ATB) ****************** - ***************************************************************** - | ! =============== | - | * ===== F =====<---------| - | ::::::::: ==== U ==== - |-->:: CTI ::&& ETB &&<......II I ======= - | ! &&&&&&&&& II I . - | ! I I . - | ! I REP I<.......... - | ! I I - | !!>&&&&&&&&& II I *Source: ARM ltd. - |------>& TPIU &<......II I DAP = Debug Access Port - &&&&&&&&& IIIIIII ETM = Embedded Trace Macrocell - ; PTM = Program Trace Macrocell - ; CTI = Cross Trigger Interface - * ETB = Embedded Trace Buffer - To trace port TPIU= Trace Port Interface Unit - SWD = Serial Wire Debug - -While on target configuration of the components is done via the APB bus, -all trace data are carried out-of-band on the ATB bus. The CTM provides -a way to aggregate and distribute signals between CoreSight components. - -The coresight framework provides a central point to represent, configure and -manage coresight devices on a platform. This first implementation centers on -the basic tracing functionality, enabling components such ETM/PTM, funnel, -replicator, TMC, TPIU and ETB. Future work will enable more -intricate IP blocks such as STM and CTI. - - -Acronyms and Classification ---------------------------- - -Acronyms: - -PTM: Program Trace Macrocell -ETM: Embedded Trace Macrocell -STM: System trace Macrocell -ETB: Embedded Trace Buffer -ITM: Instrumentation Trace Macrocell -TPIU: Trace Port Interface Unit -TMC-ETR: Trace Memory Controller, configured as Embedded Trace Router -TMC-ETF: Trace Memory Controller, configured as Embedded Trace FIFO -CTI: Cross Trigger Interface - -Classification: - -Source: - ETMv3.x ETMv4, PTMv1.0, PTMv1.1, STM, STM500, ITM -Link: - Funnel, replicator (intelligent or not), TMC-ETR -Sinks: - ETBv1.0, ETB1.1, TPIU, TMC-ETF -Misc: - CTI - - -Device Tree Bindings ----------------------- - -See Documentation/devicetree/bindings/arm/coresight.txt for details. - -As of this writing drivers for ITM, STMs and CTIs are not provided but are -expected to be added as the solution matures. - - -Framework and implementation ----------------------------- - -The coresight framework provides a central point to represent, configure and -manage coresight devices on a platform. Any coresight compliant device can -register with the framework for as long as they use the right APIs: - -struct coresight_device *coresight_register(struct coresight_desc *desc); -void coresight_unregister(struct coresight_device *csdev); - -The registering function is taking a "struct coresight_device *csdev" and -register the device with the core framework. The unregister function takes -a reference to a "struct coresight_device", obtained at registration time. - -If everything goes well during the registration process the new devices will -show up under /sys/bus/coresight/devices, as showns here for a TC2 platform: - -root:~# ls /sys/bus/coresight/devices/ -replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm -20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm -root:~# - -The functions take a "struct coresight_device", which looks like this: - -struct coresight_desc { - enum coresight_dev_type type; - struct coresight_dev_subtype subtype; - const struct coresight_ops *ops; - struct coresight_platform_data *pdata; - struct device *dev; - const struct attribute_group **groups; -}; - - -The "coresight_dev_type" identifies what the device is, i.e, source link or -sink while the "coresight_dev_subtype" will characterise that type further. - -The "struct coresight_ops" is mandatory and will tell the framework how to -perform base operations related to the components, each component having -a different set of requirement. For that "struct coresight_ops_sink", -"struct coresight_ops_link" and "struct coresight_ops_source" have been -provided. - -The next field, "struct coresight_platform_data *pdata" is acquired by calling -"of_get_coresight_platform_data()", as part of the driver's _probe routine and -"struct device *dev" gets the device reference embedded in the "amba_device": - -static int etm_probe(struct amba_device *adev, const struct amba_id *id) -{ - ... - ... - drvdata->dev = &adev->dev; - ... -} - -Specific class of device (source, link, or sink) have generic operations -that can be performed on them (see "struct coresight_ops"). The -"**groups" is a list of sysfs entries pertaining to operations -specific to that component only. "Implementation defined" customisations are -expected to be accessed and controlled using those entries. - -Last but not least, "struct module *owner" is expected to be set to reflect -the information carried in "THIS_MODULE". - -How to use the tracer modules ------------------------------ - -Before trace collection can start, a coresight sink needs to be identify. -There is no limit on the amount of sinks (nor sources) that can be enabled at -any given moment. As a generic operation, all device pertaining to the sink -class will have an "active" entry in sysfs: - -root:/sys/bus/coresight/devices# ls -replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm -20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm -root:/sys/bus/coresight/devices# ls 20010000.etb -enable_sink status trigger_cntr -root:/sys/bus/coresight/devices# echo 1 > 20010000.etb/enable_sink -root:/sys/bus/coresight/devices# cat 20010000.etb/enable_sink -1 -root:/sys/bus/coresight/devices# - -At boot time the current etm3x driver will configure the first address -comparator with "_stext" and "_etext", essentially tracing any instruction -that falls within that range. As such "enabling" a source will immediately -trigger a trace capture: - -root:/sys/bus/coresight/devices# echo 1 > 2201c000.ptm/enable_source -root:/sys/bus/coresight/devices# cat 2201c000.ptm/enable_source -1 -root:/sys/bus/coresight/devices# cat 20010000.etb/status -Depth: 0x2000 -Status: 0x1 -RAM read ptr: 0x0 -RAM wrt ptr: 0x19d3 <----- The write pointer is moving -Trigger cnt: 0x0 -Control: 0x1 -Flush status: 0x0 -Flush ctrl: 0x2001 -root:/sys/bus/coresight/devices# - -Trace collection is stopped the same way: - -root:/sys/bus/coresight/devices# echo 0 > 2201c000.ptm/enable_source -root:/sys/bus/coresight/devices# - -The content of the ETB buffer can be harvested directly from /dev: - -root:/sys/bus/coresight/devices# dd if=/dev/20010000.etb \ -of=~/cstrace.bin - -64+0 records in -64+0 records out -32768 bytes (33 kB) copied, 0.00125258 s, 26.2 MB/s -root:/sys/bus/coresight/devices# - -The file cstrace.bin can be decompressed using "ptm2human", DS-5 or Trace32. - -Following is a DS-5 output of an experimental loop that increments a variable up -to a certain value. The example is simple and yet provides a glimpse of the -wealth of possibilities that coresight provides. - -Info Tracing enabled -Instruction 106378866 0x8026B53C E52DE004 false PUSH {lr} -Instruction 0 0x8026B540 E24DD00C false SUB sp,sp,#0xc -Instruction 0 0x8026B544 E3A03000 false MOV r3,#0 -Instruction 0 0x8026B548 E58D3004 false STR r3,[sp,#4] -Instruction 0 0x8026B54C E59D3004 false LDR r3,[sp,#4] -Instruction 0 0x8026B550 E3530004 false CMP r3,#4 -Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1 -Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4] -Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c -Timestamp Timestamp: 17106715833 -Instruction 319 0x8026B54C E59D3004 false LDR r3,[sp,#4] -Instruction 0 0x8026B550 E3530004 false CMP r3,#4 -Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1 -Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4] -Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c -Instruction 9 0x8026B54C E59D3004 false LDR r3,[sp,#4] -Instruction 0 0x8026B550 E3530004 false CMP r3,#4 -Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1 -Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4] -Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c -Instruction 7 0x8026B54C E59D3004 false LDR r3,[sp,#4] -Instruction 0 0x8026B550 E3530004 false CMP r3,#4 -Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1 -Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4] -Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c -Instruction 7 0x8026B54C E59D3004 false LDR r3,[sp,#4] -Instruction 0 0x8026B550 E3530004 false CMP r3,#4 -Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1 -Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4] -Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c -Instruction 10 0x8026B54C E59D3004 false LDR r3,[sp,#4] -Instruction 0 0x8026B550 E3530004 false CMP r3,#4 -Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1 -Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4] -Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c -Instruction 6 0x8026B560 EE1D3F30 false MRC p15,#0x0,r3,c13,c0,#1 -Instruction 0 0x8026B564 E1A0100D false MOV r1,sp -Instruction 0 0x8026B568 E3C12D7F false BIC r2,r1,#0x1fc0 -Instruction 0 0x8026B56C E3C2203F false BIC r2,r2,#0x3f -Instruction 0 0x8026B570 E59D1004 false LDR r1,[sp,#4] -Instruction 0 0x8026B574 E59F0010 false LDR r0,[pc,#16] ; [0x8026B58C] = 0x80550368 -Instruction 0 0x8026B578 E592200C false LDR r2,[r2,#0xc] -Instruction 0 0x8026B57C E59221D0 false LDR r2,[r2,#0x1d0] -Instruction 0 0x8026B580 EB07A4CF true BL {pc}+0x1e9344 ; 0x804548c4 -Info Tracing enabled -Instruction 13570831 0x8026B584 E28DD00C false ADD sp,sp,#0xc -Instruction 0 0x8026B588 E8BD8000 true LDM sp!,{pc} -Timestamp Timestamp: 17107041535 - -How to use the STM module -------------------------- - -Using the System Trace Macrocell module is the same as the tracers - the only -difference is that clients are driving the trace capture rather -than the program flow through the code. - -As with any other CoreSight component, specifics about the STM tracer can be -found in sysfs with more information on each entry being found in [1]: - -root@genericarmv8:~# ls /sys/bus/coresight/devices/20100000.stm -enable_source hwevent_select port_enable subsystem uevent -hwevent_enable mgmt port_select traceid -root@genericarmv8:~# - -Like any other source a sink needs to be identified and the STM enabled before -being used: - -root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20010000.etf/enable_sink -root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20100000.stm/enable_source - -From there user space applications can request and use channels using the devfs -interface provided for that purpose by the generic STM API: - -root@genericarmv8:~# ls -l /dev/20100000.stm -crw------- 1 root root 10, 61 Jan 3 18:11 /dev/20100000.stm -root@genericarmv8:~# - -Details on how to use the generic STM API can be found here [2]. - -[1]. Documentation/ABI/testing/sysfs-bus-coresight-devices-stm -[2]. Documentation/trace/stm.txt diff --git a/Documentation/trace/coresight/coresight-cpu-debug.txt b/Documentation/trace/coresight/coresight-cpu-debug.txt new file mode 100644 index 0000000..2b9b51c --- /dev/null +++ b/Documentation/trace/coresight/coresight-cpu-debug.txt @@ -0,0 +1,187 @@ + Coresight CPU Debug Module + ========================== + + Author: Leo Yan + Date: April 5th, 2017 + +Introduction +------------ + +Coresight CPU debug module is defined in ARMv8-a architecture reference manual +(ARM DDI 0487A.k) Chapter 'Part H: External debug', the CPU can integrate +debug module and it is mainly used for two modes: self-hosted debug and +external debug. Usually the external debug mode is well known as the external +debugger connects with SoC from JTAG port; on the other hand the program can +explore debugging method which rely on self-hosted debug mode, this document +is to focus on this part. + +The debug module provides sample-based profiling extension, which can be used +to sample CPU program counter, secure state and exception level, etc; usually +every CPU has one dedicated debug module to be connected. Based on self-hosted +debug mechanism, Linux kernel can access these related registers from mmio +region when the kernel panic happens. The callback notifier for kernel panic +will dump related registers for every CPU; finally this is good for assistant +analysis for panic. + + +Implementation +-------------- + +- During driver registration, it uses EDDEVID and EDDEVID1 - two device ID + registers to decide if sample-based profiling is implemented or not. On some + platforms this hardware feature is fully or partially implemented; and if + this feature is not supported then registration will fail. + +- At the time this documentation was written, the debug driver mainly relies on + information gathered by the kernel panic callback notifier from three + sampling registers: EDPCSR, EDVIDSR and EDCIDSR: from EDPCSR we can get + program counter; EDVIDSR has information for secure state, exception level, + bit width, etc; EDCIDSR is context ID value which contains the sampled value + of CONTEXTIDR_EL1. + +- The driver supports a CPU running in either AArch64 or AArch32 mode. The + registers naming convention is a bit different between them, AArch64 uses + 'ED' for register prefix (ARM DDI 0487A.k, chapter H9.1) and AArch32 uses + 'DBG' as prefix (ARM DDI 0487A.k, chapter G5.1). The driver is unified to + use AArch64 naming convention. + +- ARMv8-a (ARM DDI 0487A.k) and ARMv7-a (ARM DDI 0406C.b) have different + register bits definition. So the driver consolidates two difference: + + If PCSROffset=0b0000, on ARMv8-a the feature of EDPCSR is not implemented; + but ARMv7-a defines "PCSR samples are offset by a value that depends on the + instruction set state". For ARMv7-a, the driver checks furthermore if CPU + runs with ARM or thumb instruction set and calibrate PCSR value, the + detailed description for offset is in ARMv7-a ARM (ARM DDI 0406C.b) chapter + C11.11.34 "DBGPCSR, Program Counter Sampling Register". + + If PCSROffset=0b0010, ARMv8-a defines "EDPCSR implemented, and samples have + no offset applied and do not sample the instruction set state in AArch32 + state". So on ARMv8 if EDDEVID1.PCSROffset is 0b0010 and the CPU operates + in AArch32 state, EDPCSR is not sampled; when the CPU operates in AArch64 + state EDPCSR is sampled and no offset are applied. + + +Clock and power domain +---------------------- + +Before accessing debug registers, we should ensure the clock and power domain +have been enabled properly. In ARMv8-a ARM (ARM DDI 0487A.k) chapter 'H9.1 +Debug registers', the debug registers are spread into two domains: the debug +domain and the CPU domain. + + +---------------+ + | | + | | + +----------+--+ | + dbg_clock -->| |**| |<-- cpu_clock + | Debug |**| CPU | + dbg_power_domain -->| |**| |<-- cpu_power_domain + +----------+--+ | + | | + | | + +---------------+ + +For debug domain, the user uses DT binding "clocks" and "power-domains" to +specify the corresponding clock source and power supply for the debug logic. +The driver calls the pm_runtime_{put|get} operations as needed to handle the +debug power domain. + +For CPU domain, the different SoC designs have different power management +schemes and finally this heavily impacts external debug module. So we can +divide into below cases: + +- On systems with a sane power controller which can behave correctly with + respect to CPU power domain, the CPU power domain can be controlled by + register EDPRCR in driver. The driver firstly writes bit EDPRCR.COREPURQ + to power up the CPU, and then writes bit EDPRCR.CORENPDRQ for emulation + of CPU power down. As result, this can ensure the CPU power domain is + powered on properly during the period when access debug related registers; + +- Some designs will power down an entire cluster if all CPUs on the cluster + are powered down - including the parts of the debug registers that should + remain powered in the debug power domain. The bits in EDPRCR are not + respected in these cases, so these designs do not support debug over + power down in the way that the CoreSight / Debug designers anticipated. + This means that even checking EDPRSR has the potential to cause a bus hang + if the target register is unpowered. + + In this case, accessing to the debug registers while they are not powered + is a recipe for disaster; so we need preventing CPU low power states at boot + time or when user enable module at the run time. Please see chapter + "How to use the module" for detailed usage info for this. + + +Device Tree Bindings +-------------------- + +See Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt for details. + + +How to use the module +--------------------- + +If you want to enable debugging functionality at boot time, you can add +"coresight_cpu_debug.enable=1" to the kernel command line parameter. + +The driver also can work as module, so can enable the debugging when insmod +module: +# insmod coresight_cpu_debug.ko debug=1 + +When boot time or insmod module you have not enabled the debugging, the driver +uses the debugfs file system to provide a knob to dynamically enable or disable +debugging: + +To enable it, write a '1' into /sys/kernel/debug/coresight_cpu_debug/enable: +# echo 1 > /sys/kernel/debug/coresight_cpu_debug/enable + +To disable it, write a '0' into /sys/kernel/debug/coresight_cpu_debug/enable: +# echo 0 > /sys/kernel/debug/coresight_cpu_debug/enable + +As explained in chapter "Clock and power domain", if you are working on one +platform which has idle states to power off debug logic and the power +controller cannot work well for the request from EDPRCR, then you should +firstly constraint CPU idle states before enable CPU debugging feature; so can +ensure the accessing to debug logic. + +If you want to limit idle states at boot time, you can use "nohlt" or +"cpuidle.off=1" in the kernel command line. + +At the runtime you can disable idle states with below methods: + +It is possible to disable CPU idle states by way of the PM QoS +subsystem, more specifically by using the "/dev/cpu_dma_latency" +interface (see Documentation/power/pm_qos_interface.txt for more +details). As specified in the PM QoS documentation the requested +parameter will stay in effect until the file descriptor is released. +For example: + +# exec 3<> /dev/cpu_dma_latency; echo 0 >&3 +... +Do some work... +... +# exec 3<>- + +The same can also be done from an application program. + +Disable specific CPU's specific idle state from cpuidle sysfs (see +Documentation/cpuidle/sysfs.txt): +# echo 1 > /sys/devices/system/cpu/cpu$cpu/cpuidle/state$state/disable + + +Output format +------------- + +Here is an example of the debugging output format: + +ARM external debug module: +coresight-cpu-debug 850000.debug: CPU[0]: +coresight-cpu-debug 850000.debug: EDPRSR: 00000001 (Power:On DLK:Unlock) +coresight-cpu-debug 850000.debug: EDPCSR: [] handle_IPI+0x174/0x1d8 +coresight-cpu-debug 850000.debug: EDCIDSR: 00000000 +coresight-cpu-debug 850000.debug: EDVIDSR: 90000000 (State:Non-secure Mode:EL1/0 Width:64bits VMID:0) +coresight-cpu-debug 852000.debug: CPU[1]: +coresight-cpu-debug 852000.debug: EDPRSR: 00000001 (Power:On DLK:Unlock) +coresight-cpu-debug 852000.debug: EDPCSR: [] debug_notifier_call+0x23c/0x358 +coresight-cpu-debug 852000.debug: EDCIDSR: 00000000 +coresight-cpu-debug 852000.debug: EDVIDSR: 90000000 (State:Non-secure Mode:EL1/0 Width:64bits VMID:0) diff --git a/Documentation/trace/coresight/coresight.txt b/Documentation/trace/coresight/coresight.txt new file mode 100644 index 0000000..a33c88c --- /dev/null +++ b/Documentation/trace/coresight/coresight.txt @@ -0,0 +1,332 @@ + Coresight - HW Assisted Tracing on ARM + ====================================== + + Author: Mathieu Poirier + Date: September 11th, 2014 + +Introduction +------------ + +Coresight is an umbrella of technologies allowing for the debugging of ARM +based SoC. It includes solutions for JTAG and HW assisted tracing. This +document is concerned with the latter. + +HW assisted tracing is becoming increasingly useful when dealing with systems +that have many SoCs and other components like GPU and DMA engines. ARM has +developed a HW assisted tracing solution by means of different components, each +being added to a design at synthesis time to cater to specific tracing needs. +Components are generally categorised as source, link and sinks and are +(usually) discovered using the AMBA bus. + +"Sources" generate a compressed stream representing the processor instruction +path based on tracing scenarios as configured by users. From there the stream +flows through the coresight system (via ATB bus) using links that are connecting +the emanating source to a sink(s). Sinks serve as endpoints to the coresight +implementation, either storing the compressed stream in a memory buffer or +creating an interface to the outside world where data can be transferred to a +host without fear of filling up the onboard coresight memory buffer. + +At typical coresight system would look like this: + + ***************************************************************** + **************************** AMBA AXI ****************************===|| + ***************************************************************** || + ^ ^ | || + | | * ** + 0000000 ::::: 0000000 ::::: ::::: @@@@@@@ |||||||||||| + 0 CPU 0<-->: C : 0 CPU 0<-->: C : : C : @ STM @ || System || + |->0000000 : T : |->0000000 : T : : T :<--->@@@@@ || Memory || + | #######<-->: I : | #######<-->: I : : I : @@@<-| |||||||||||| + | # ETM # ::::: | # PTM # ::::: ::::: @ | + | ##### ^ ^ | ##### ^ ! ^ ! . | ||||||||| + | |->### | ! | |->### | ! | ! . | || DAP || + | | # | ! | | # | ! | ! . | ||||||||| + | | . | ! | | . | ! | ! . | | | + | | . | ! | | . | ! | ! . | | * + | | . | ! | | . | ! | ! . | | SWD/ + | | . | ! | | . | ! | ! . | | JTAG + *****************************************************************<-| + *************************** AMBA Debug APB ************************ + ***************************************************************** + | . ! . ! ! . | + | . * . * * . | + ***************************************************************** + ******************** Cross Trigger Matrix (CTM) ******************* + ***************************************************************** + | . ^ . . | + | * ! * * | + ***************************************************************** + ****************** AMBA Advanced Trace Bus (ATB) ****************** + ***************************************************************** + | ! =============== | + | * ===== F =====<---------| + | ::::::::: ==== U ==== + |-->:: CTI ::&& ETB &&<......II I ======= + | ! &&&&&&&&& II I . + | ! I I . + | ! I REP I<.......... + | ! I I + | !!>&&&&&&&&& II I *Source: ARM ltd. + |------>& TPIU &<......II I DAP = Debug Access Port + &&&&&&&&& IIIIIII ETM = Embedded Trace Macrocell + ; PTM = Program Trace Macrocell + ; CTI = Cross Trigger Interface + * ETB = Embedded Trace Buffer + To trace port TPIU= Trace Port Interface Unit + SWD = Serial Wire Debug + +While on target configuration of the components is done via the APB bus, +all trace data are carried out-of-band on the ATB bus. The CTM provides +a way to aggregate and distribute signals between CoreSight components. + +The coresight framework provides a central point to represent, configure and +manage coresight devices on a platform. This first implementation centers on +the basic tracing functionality, enabling components such ETM/PTM, funnel, +replicator, TMC, TPIU and ETB. Future work will enable more +intricate IP blocks such as STM and CTI. + + +Acronyms and Classification +--------------------------- + +Acronyms: + +PTM: Program Trace Macrocell +ETM: Embedded Trace Macrocell +STM: System trace Macrocell +ETB: Embedded Trace Buffer +ITM: Instrumentation Trace Macrocell +TPIU: Trace Port Interface Unit +TMC-ETR: Trace Memory Controller, configured as Embedded Trace Router +TMC-ETF: Trace Memory Controller, configured as Embedded Trace FIFO +CTI: Cross Trigger Interface + +Classification: + +Source: + ETMv3.x ETMv4, PTMv1.0, PTMv1.1, STM, STM500, ITM +Link: + Funnel, replicator (intelligent or not), TMC-ETR +Sinks: + ETBv1.0, ETB1.1, TPIU, TMC-ETF +Misc: + CTI + + +Device Tree Bindings +---------------------- + +See Documentation/devicetree/bindings/arm/coresight.txt for details. + +As of this writing drivers for ITM, STMs and CTIs are not provided but are +expected to be added as the solution matures. + + +Framework and implementation +---------------------------- + +The coresight framework provides a central point to represent, configure and +manage coresight devices on a platform. Any coresight compliant device can +register with the framework for as long as they use the right APIs: + +struct coresight_device *coresight_register(struct coresight_desc *desc); +void coresight_unregister(struct coresight_device *csdev); + +The registering function is taking a "struct coresight_device *csdev" and +register the device with the core framework. The unregister function takes +a reference to a "struct coresight_device", obtained at registration time. + +If everything goes well during the registration process the new devices will +show up under /sys/bus/coresight/devices, as showns here for a TC2 platform: + +root:~# ls /sys/bus/coresight/devices/ +replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm +20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm +root:~# + +The functions take a "struct coresight_device", which looks like this: + +struct coresight_desc { + enum coresight_dev_type type; + struct coresight_dev_subtype subtype; + const struct coresight_ops *ops; + struct coresight_platform_data *pdata; + struct device *dev; + const struct attribute_group **groups; +}; + + +The "coresight_dev_type" identifies what the device is, i.e, source link or +sink while the "coresight_dev_subtype" will characterise that type further. + +The "struct coresight_ops" is mandatory and will tell the framework how to +perform base operations related to the components, each component having +a different set of requirement. For that "struct coresight_ops_sink", +"struct coresight_ops_link" and "struct coresight_ops_source" have been +provided. + +The next field, "struct coresight_platform_data *pdata" is acquired by calling +"of_get_coresight_platform_data()", as part of the driver's _probe routine and +"struct device *dev" gets the device reference embedded in the "amba_device": + +static int etm_probe(struct amba_device *adev, const struct amba_id *id) +{ + ... + ... + drvdata->dev = &adev->dev; + ... +} + +Specific class of device (source, link, or sink) have generic operations +that can be performed on them (see "struct coresight_ops"). The +"**groups" is a list of sysfs entries pertaining to operations +specific to that component only. "Implementation defined" customisations are +expected to be accessed and controlled using those entries. + +Last but not least, "struct module *owner" is expected to be set to reflect +the information carried in "THIS_MODULE". + +How to use the tracer modules +----------------------------- + +Before trace collection can start, a coresight sink needs to be identify. +There is no limit on the amount of sinks (nor sources) that can be enabled at +any given moment. As a generic operation, all device pertaining to the sink +class will have an "active" entry in sysfs: + +root:/sys/bus/coresight/devices# ls +replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm +20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm +root:/sys/bus/coresight/devices# ls 20010000.etb +enable_sink status trigger_cntr +root:/sys/bus/coresight/devices# echo 1 > 20010000.etb/enable_sink +root:/sys/bus/coresight/devices# cat 20010000.etb/enable_sink +1 +root:/sys/bus/coresight/devices# + +At boot time the current etm3x driver will configure the first address +comparator with "_stext" and "_etext", essentially tracing any instruction +that falls within that range. As such "enabling" a source will immediately +trigger a trace capture: + +root:/sys/bus/coresight/devices# echo 1 > 2201c000.ptm/enable_source +root:/sys/bus/coresight/devices# cat 2201c000.ptm/enable_source +1 +root:/sys/bus/coresight/devices# cat 20010000.etb/status +Depth: 0x2000 +Status: 0x1 +RAM read ptr: 0x0 +RAM wrt ptr: 0x19d3 <----- The write pointer is moving +Trigger cnt: 0x0 +Control: 0x1 +Flush status: 0x0 +Flush ctrl: 0x2001 +root:/sys/bus/coresight/devices# + +Trace collection is stopped the same way: + +root:/sys/bus/coresight/devices# echo 0 > 2201c000.ptm/enable_source +root:/sys/bus/coresight/devices# + +The content of the ETB buffer can be harvested directly from /dev: + +root:/sys/bus/coresight/devices# dd if=/dev/20010000.etb \ +of=~/cstrace.bin + +64+0 records in +64+0 records out +32768 bytes (33 kB) copied, 0.00125258 s, 26.2 MB/s +root:/sys/bus/coresight/devices# + +The file cstrace.bin can be decompressed using "ptm2human", DS-5 or Trace32. + +Following is a DS-5 output of an experimental loop that increments a variable up +to a certain value. The example is simple and yet provides a glimpse of the +wealth of possibilities that coresight provides. + +Info Tracing enabled +Instruction 106378866 0x8026B53C E52DE004 false PUSH {lr} +Instruction 0 0x8026B540 E24DD00C false SUB sp,sp,#0xc +Instruction 0 0x8026B544 E3A03000 false MOV r3,#0 +Instruction 0 0x8026B548 E58D3004 false STR r3,[sp,#4] +Instruction 0 0x8026B54C E59D3004 false LDR r3,[sp,#4] +Instruction 0 0x8026B550 E3530004 false CMP r3,#4 +Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1 +Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4] +Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c +Timestamp Timestamp: 17106715833 +Instruction 319 0x8026B54C E59D3004 false LDR r3,[sp,#4] +Instruction 0 0x8026B550 E3530004 false CMP r3,#4 +Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1 +Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4] +Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c +Instruction 9 0x8026B54C E59D3004 false LDR r3,[sp,#4] +Instruction 0 0x8026B550 E3530004 false CMP r3,#4 +Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1 +Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4] +Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c +Instruction 7 0x8026B54C E59D3004 false LDR r3,[sp,#4] +Instruction 0 0x8026B550 E3530004 false CMP r3,#4 +Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1 +Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4] +Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c +Instruction 7 0x8026B54C E59D3004 false LDR r3,[sp,#4] +Instruction 0 0x8026B550 E3530004 false CMP r3,#4 +Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1 +Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4] +Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c +Instruction 10 0x8026B54C E59D3004 false LDR r3,[sp,#4] +Instruction 0 0x8026B550 E3530004 false CMP r3,#4 +Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1 +Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4] +Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c +Instruction 6 0x8026B560 EE1D3F30 false MRC p15,#0x0,r3,c13,c0,#1 +Instruction 0 0x8026B564 E1A0100D false MOV r1,sp +Instruction 0 0x8026B568 E3C12D7F false BIC r2,r1,#0x1fc0 +Instruction 0 0x8026B56C E3C2203F false BIC r2,r2,#0x3f +Instruction 0 0x8026B570 E59D1004 false LDR r1,[sp,#4] +Instruction 0 0x8026B574 E59F0010 false LDR r0,[pc,#16] ; [0x8026B58C] = 0x80550368 +Instruction 0 0x8026B578 E592200C false LDR r2,[r2,#0xc] +Instruction 0 0x8026B57C E59221D0 false LDR r2,[r2,#0x1d0] +Instruction 0 0x8026B580 EB07A4CF true BL {pc}+0x1e9344 ; 0x804548c4 +Info Tracing enabled +Instruction 13570831 0x8026B584 E28DD00C false ADD sp,sp,#0xc +Instruction 0 0x8026B588 E8BD8000 true LDM sp!,{pc} +Timestamp Timestamp: 17107041535 + +How to use the STM module +------------------------- + +Using the System Trace Macrocell module is the same as the tracers - the only +difference is that clients are driving the trace capture rather +than the program flow through the code. + +As with any other CoreSight component, specifics about the STM tracer can be +found in sysfs with more information on each entry being found in [1]: + +root@genericarmv8:~# ls /sys/bus/coresight/devices/20100000.stm +enable_source hwevent_select port_enable subsystem uevent +hwevent_enable mgmt port_select traceid +root@genericarmv8:~# + +Like any other source a sink needs to be identified and the STM enabled before +being used: + +root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20010000.etf/enable_sink +root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20100000.stm/enable_source + +From there user space applications can request and use channels using the devfs +interface provided for that purpose by the generic STM API: + +root@genericarmv8:~# ls -l /dev/20100000.stm +crw------- 1 root root 10, 61 Jan 3 18:11 /dev/20100000.stm +root@genericarmv8:~# + +Details on how to use the generic STM API can be found here [2]. + +[1]. Documentation/ABI/testing/sysfs-bus-coresight-devices-stm +[2]. Documentation/trace/stm.txt diff --git a/MAINTAINERS b/MAINTAINERS index 4641719..d7a6fc7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1307,8 +1307,8 @@ M: Mathieu Poirier L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers) S: Maintained F: drivers/hwtracing/coresight/* -F: Documentation/trace/coresight.txt -F: Documentation/trace/coresight-cpu-debug.txt +F: Documentation/trace/coresight/coresight.txt +F: Documentation/trace/coresight/coresight-cpu-debug.txt F: Documentation/devicetree/bindings/arm/coresight.txt F: Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt F: Documentation/ABI/testing/sysfs-bus-coresight-devices-* From patchwork Thu Dec 21 08:20:11 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Leo Yan X-Patchwork-Id: 122515 Delivered-To: patch@linaro.org Received: by 10.140.22.227 with SMTP id 90csp580422qgn; Thu, 21 Dec 2017 00:21:01 -0800 (PST) X-Google-Smtp-Source: ACJfBou4cPiJJJ1+7eLW9nRni0ngkbKxngLBuQIV6Jv+wroymuauM8THleixMZlkOqkPG5Fgky+0 X-Received: by 10.99.159.2 with SMTP id g2mr8910540pge.240.1513844461426; Thu, 21 Dec 2017 00:21:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1513844461; cv=none; d=google.com; s=arc-20160816; b=IwDvIhHKdn1UuJrrBQoADtBIFCGjVov95T79xdaOOPn6Yj8jfJfq/FsCpabMCnPXtj mP3ZXNW0Ru2Zrk6pX8XPkThmd5ZYkCOeUZGv3wCZ2dxLGoDEbfZNIVdsiF1NHUNcGkM3 qpki02GqXoueCjSdnXD2AmkycCg4wS5snrMVPdrDkC+yEwYi2Wef1PzEzgj/mdVThHhA vcjHfc+MkfdUw4rYDvaHAEyUd8oPuRzuQsz9NYohhyAnFaAGzBg2edDoHmjp7DCHxfbL 2DcqtvpQuUKu49VdfqAsptH1WeNA+fM/rfcSEfj+L/6XHGShcfSE7dc5L0qbLVyd0s8D 2dBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=24EyWKlM2VrmVqohn9HBsDzFsotx0DFZspF9D9RbzmM=; b=ayopL3GK2txuA63fN6b6Wm53fp3m9ukpPe1Oz5ItHO2vk2wnOhHfreLPGOC0iqxbdV 3G/ZULap3ZhFGoDZUjVb2D6vU9roE5DnVZIvrRc9fLjbMZFH8yT86yqfSDFaVD6RygTX S6+89bWhYSyhTP032dskJ+pbnPgZEed+DhhosXIw88wJBQ2x6tYZ3tb9MJoei7Co+gYi avZnuVbeaE5h7gh2TDfOIVtbi5hXU6W4Y3rP0lRpvbx+Qn/cvh16WzscOUZla6zvagze m29j2dw7ZLQLfSFY/KLaRw7RHf6b4U02PedilkIoLvMovMG2+gs/9e3dbS+sIMaSy3sA YHFQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=TOws2kjk; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b3si14397869plb.41.2017.12.21.00.21.01; Thu, 21 Dec 2017 00:21:01 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=TOws2kjk; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751777AbdLUIU5 (ORCPT + 28 others); Thu, 21 Dec 2017 03:20:57 -0500 Received: from mail-pl0-f68.google.com ([209.85.160.68]:41716 "EHLO mail-pl0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750782AbdLUIUs (ORCPT ); Thu, 21 Dec 2017 03:20:48 -0500 Received: by mail-pl0-f68.google.com with SMTP id g2so10587476pli.8 for ; Thu, 21 Dec 2017 00:20:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=24EyWKlM2VrmVqohn9HBsDzFsotx0DFZspF9D9RbzmM=; b=TOws2kjkk+942kH42zRnlN+mIBwAHZz/8gnff8GR0vRHGebx0K8c6EXcTuzYdJct9x 1l/T1WjXSkI03SI7yK+VdVr78GqxAeiMafspWDTl4v0SA+P9arUujQPJ1hMSDDYP/0kh 7XqqUq1P8yLbeQGrRhPqBR1u/zTVz9DTZVcV8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=24EyWKlM2VrmVqohn9HBsDzFsotx0DFZspF9D9RbzmM=; b=bZ3NcPVAx4CbBmVH4Il4P1nX0sjx1c55S1Id7fNxSzspxLeRbW6yTE/nnG7UQ52uOD ZR/h1eP37MUBjcwf9/F50uweht/Yhd/5cOkQTNFkzydJyVRlvnCTVgr5oTic8GMonieD WGIPM2/T5dAUr3dlG0WtZ4iAsUjlEu+Qr5AAFFZo0FKOXqqLAsU5/33GY20Rnr3PVkoO xvY/hGi66s2da3AXSat4b3L96LxoZ35+17P0MB6y1sloSyuRDDog9pbptNmbkYelmUNT AxLgcHTb8TlH8wV2YxuABPI2RZPZYGZLfLLNttp717PZGoVJE6jyd0/2rnbJ4U+LjcCA MOjA== X-Gm-Message-State: AKGB3mJigeZwFnL37VSh8IkfgditHA3dvWg4qPNo9qcxKOryEFd2OVqD msApkCzl/BprX50FnLCrD6g7Kg== X-Received: by 10.84.172.195 with SMTP id n61mr9798441plb.49.1513844448043; Thu, 21 Dec 2017 00:20:48 -0800 (PST) Received: from localhost.localdomain (li159-223.members.linode.com. [173.230.149.223]) by smtp.gmail.com with ESMTPSA id r86sm43699720pfk.114.2017.12.21.00.20.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Dec 2017 00:20:46 -0800 (PST) From: Leo Yan To: Jonathan Corbet , Mathieu Poirier , Greg Kroah-Hartman , Will Deacon , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, coresight@lists.linaro.org Cc: Leo Yan Subject: [PATCH v3 2/6] doc: Add documentation for Coresight panic kdump Date: Thu, 21 Dec 2017 16:20:11 +0800 Message-Id: <1513844415-11427-3-git-send-email-leo.yan@linaro.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1513844415-11427-1-git-send-email-leo.yan@linaro.org> References: <1513844415-11427-1-git-send-email-leo.yan@linaro.org> MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Add detailed documentation for Coresight panic kdump, which contains the idea for why need this and introduce the framework implementation and usage. Signed-off-by: Leo Yan --- .../trace/coresight/coresight-panic-kdump.txt | 91 ++++++++++++++++++++++ MAINTAINERS | 1 + 2 files changed, 92 insertions(+) create mode 100644 Documentation/trace/coresight/coresight-panic-kdump.txt -- 2.7.4 diff --git a/Documentation/trace/coresight/coresight-panic-kdump.txt b/Documentation/trace/coresight/coresight-panic-kdump.txt new file mode 100644 index 0000000..6bf9cac --- /dev/null +++ b/Documentation/trace/coresight/coresight-panic-kdump.txt @@ -0,0 +1,91 @@ + Coresight Panic Kdump + ===================== + + Author: Leo Yan + Date: Dec 21th, 2017 + +Introduction +------------ + +Coresight has different sinks for trace data, the trace data is quite useful +for postmortem debugging. Embedded Trace Buffer (ETB) is one type sink which +provides on-chip storage of trace data, usually uses SRAM as buffer with +several KBs size; if the SoC designs to support 'Local ETF' (ARM DDI 0461B, +chapter 1.2.7), every CPU has one local ETB buffer so the per CPU trace data +can avoid to be overwritted by other CPUs. Trace Memory Controller (TMC) is +another kind sink designed as a successor to the CoreSight ETB to capture trace +into DRAM. + +After Linux kernel trigger panic, the trace data keeps the last execution flow +before issues happen. We could consider the trace data is quite useful for +postmortem debugging, especially when we can record trace data into DRAM and rely +on kdump to save them into vmcore file; at the end we can retrieve trace data +from vmcore file and "offline" to analyze the execution flow. + + +Implementation +-------------- + +Coresight panic kdump is a simple framework to support dump functionality, +it maintains dump list with every node recording the dump buffer base address +and buffer size. Coresight panic kdump provides the general APIs +{coresight_kdump_add|coresight_kdump_del} as helper functions so any coresight +device can add itself into dump list or delete as needed. + +Generally coresight device set its 'panic_cb' in the ops structure, the panic +notifier iterates dump list and invokes callback function to dump device specific +info. + +For easily used by offline analysis, we also record tracer metadata so can +retrieve tracer IDs and configuration, in this case the node records CPU number so +can create connection between the metadata and specific CPU. The tracer +driver uses helper function coresight_kdump_update() to update the dump +buffer base address and buffer size; so the tracer can save metadata at runtime +and these info can be prepared well pre panic happening. + + +Usage +----- + +Build Linux kernel with enabling 'CONFIG_CORESIGHT_PANIC_KDUMP' configuration. + +After system booting up, we need firstly prepare dump-capture kernel, this can +refer doc [1] chapter 'Load the Dump-capture Kernel' for detailed steps. Then +we need enable the coresight tracer, this can use either perf framework method +or sysFS interface, please refer doc [2] chapter 'How to use the tracer modules' +for detailed steps. + +When kernel panic happens, the panic kdump records trace data and launches +dump-capture kernel, we can utilize the dump-capture kernel to save kernel dump +file, this can refer doc [1] chapter 'Write Out the Dump File'. + +After get kernel dump file, we can use 'crash' tool + csdump.so extension to +extract trace data and generate 'perf.data' file: + + ./crash vmcore vmlinux + crash> extend csdump.so + crash> csdump output_dir + + We can see in the 'output_dir' there will generate out three files: + output_dir/ + ├── cstrace.bin -> trace raw data + ├── metadata.bin -> meta data + └── perf.data -> 'perf' format compatible file + +Finally use 'perf' tool for offline analysis: + + ./perf script -v -F cpu,event,ip,sym,symoff -i perf.data -k vmlinux --kallsyms /proc/kallsyms + [001] instructions: ffff000008559ad0 pl011_console_write+0x90 + [001] instructions: ffff000008559230 pl011_read+0x0 + [001] instructions: ffff00000855924c pl011_read+0x1c + [001] instructions: ffff000008559ae0 pl011_console_write+0xa0 + [001] instructions: ffff000008559ad0 pl011_console_write+0x90 + [001] instructions: ffff000008559230 pl011_read+0x0 + [001] instructions: ffff00000855924c pl011_read+0x1c + [001] instructions: ffff000008559ae0 pl011_console_write+0xa0 + [001] instructions: ffff000008559ad0 pl011_console_write+0x90 + [001] instructions: ffff000008559230 pl011_read+0x0 + [001] instructions: ffff00000855924c pl011_read+0x1c + +[1] Documentation/kdump/kdump.txt +[2] Documentation/trace/coresight/coresight.txt diff --git a/MAINTAINERS b/MAINTAINERS index d7a6fc7..26276e0 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1309,6 +1309,7 @@ S: Maintained F: drivers/hwtracing/coresight/* F: Documentation/trace/coresight/coresight.txt F: Documentation/trace/coresight/coresight-cpu-debug.txt +F: Documentation/trace/coresight/coresight-panic-kdump.txt F: Documentation/devicetree/bindings/arm/coresight.txt F: Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt F: Documentation/ABI/testing/sysfs-bus-coresight-devices-* From patchwork Thu Dec 21 08:20:12 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leo Yan X-Patchwork-Id: 122516 Delivered-To: patch@linaro.org Received: by 10.140.22.227 with SMTP id 90csp580459qgn; Thu, 21 Dec 2017 00:21:05 -0800 (PST) X-Google-Smtp-Source: ACJfBouxOHXpT6pybEdQAgTNq4TbhOVMzBfrC9WhpdKTcEE/iH0+vCnRncIRQS+e24qNlXxIXdK/ X-Received: by 10.84.217.14 with SMTP id o14mr9991180pli.169.1513844464762; Thu, 21 Dec 2017 00:21:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1513844464; cv=none; d=google.com; s=arc-20160816; b=T7GjDlFMb6LPNgnrvte3plCHhhqV5GObQFN3dUis3LuVJ2OyU3VJxtUoSm6ygtVOtF EvLKETahfephwyrL7WyQsBdgEKbEGK2I1kKwnz4B4q0lLwiTcsyLPdUgDRnwiOGwKvWZ KNjO2zx+R5ugFVze8fDoFFjQ0TvNyXfqHa+WxEQPfM7J44TcBp/xBCpbaSJtDa9W92Jf Vh0QHep/4sPYgqxV9RW2E46ZLdVZBGgfF+F/PgZg1KGVo0Ur/E1YMyjXyKSlQzTB5b2N PmvznmKWl7y8RqnqZoNtQMXljCSOa3klYU+MqAe+ZreDBsGtEuK2PV5e2UcnYLVXtlyS ioPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=9JYwaGUC0An/axs8tCXKpUNaJOc1/MZD9kXVLyjpgqA=; b=XKEN+cXz/w4nsQb+rzvXXCTBHZKpr0pTyJn/LKMo+YluHIsUbrwYr733yZdSUqU0Nw 8OVdb/VZssA9TMNvQKuLFFlLhldAeNsAJC51YwcewEilY6T2w4FvlpZLtJw2rCiNFoB0 aHtRW9Rt6nKrGCkjGdtGjyYa8M8tTQLF3dNgpSuADFjXR6hBPiPtWQaxwsalnZAUco7y kxnp+7KCdj/7qzhR64uRBBy3m59WOCDAnUciBJcfuKyr9hXS38FLSjBFq37G+tqK9YRk 6gjCg8U3uViCkFY70W1eyd70RYAC/0Zt43a7PMrK2wNn/Yzn35Q8UbwKJKiNjSYG5y75 mSvw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=hSCIzdtB; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 8si14568944pfo.144.2017.12.21.00.21.04; Thu, 21 Dec 2017 00:21:04 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=hSCIzdtB; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751842AbdLUIVB (ORCPT + 28 others); Thu, 21 Dec 2017 03:21:01 -0500 Received: from mail-pl0-f65.google.com ([209.85.160.65]:44571 "EHLO mail-pl0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751685AbdLUIUx (ORCPT ); Thu, 21 Dec 2017 03:20:53 -0500 Received: by mail-pl0-f65.google.com with SMTP id n13so10586560plp.11 for ; Thu, 21 Dec 2017 00:20:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=9JYwaGUC0An/axs8tCXKpUNaJOc1/MZD9kXVLyjpgqA=; b=hSCIzdtBO5d5Vj++O8/dGOwC+Ym2KnFrRBn8JmNnVjFBFSz9TjHSOdMyhhtlZCehW/ wgYINh4TG4M1cqJjU7fBrZn4LZBCW7KVf6yYK351pDSds9m7QNXb+XBo+MJvilGjGH3i lR9zW81CO20ezPL8kyQkTcQcuyTVOxSBw/6BA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=9JYwaGUC0An/axs8tCXKpUNaJOc1/MZD9kXVLyjpgqA=; b=Wyf/GEYG+lRf93DuSmY4L25IKMSXYxJTd94HQ3Z4BygnxnLZtjOmOkPMn101LUo0fC 6fyRND6WmgH2ziG5g+1hTfqNgFXvs2xzIppuMUBPPuTVRNBH8VLm0J8tW32aSh4Sk8yh ZdG1HBmR3cm+DGuiY66KZSSOlX0deNgHn6/Ael1JKM3pzb4xNEWWfoWMo4sZZZfwd4XR 7ZSoQOCvJoPkpD/0HAIoYboZ+7bQzFNn/80kG/fTeCJ/VEnht3ZN0Y6qkntVkmtZOoFE qeuJylC4r+zJ8ctvcMsUJyi0C1MRxUHcuxulnFA+chQyJkVatgRvggy8TE0+R+xnWdIm X5Tw== X-Gm-Message-State: AKGB3mL9BQG8oxlmMJD7DrylH6+U7ZpSy8lJByJkn/+WwLPNcH0teFbe cq0oKR91guLaIAahlRdlNezgAw== X-Received: by 10.84.218.193 with SMTP id g1mr9779075plm.63.1513844452764; Thu, 21 Dec 2017 00:20:52 -0800 (PST) Received: from localhost.localdomain (li159-223.members.linode.com. [173.230.149.223]) by smtp.gmail.com with ESMTPSA id r86sm43699720pfk.114.2017.12.21.00.20.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Dec 2017 00:20:51 -0800 (PST) From: Leo Yan To: Jonathan Corbet , Mathieu Poirier , Greg Kroah-Hartman , Will Deacon , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, coresight@lists.linaro.org Cc: Leo Yan Subject: [PATCH v3 3/6] coresight: Support panic kdump functionality Date: Thu, 21 Dec 2017 16:20:12 +0800 Message-Id: <1513844415-11427-4-git-send-email-leo.yan@linaro.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1513844415-11427-1-git-send-email-leo.yan@linaro.org> References: <1513844415-11427-1-git-send-email-leo.yan@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org After kernel panic happens, coresight has many useful info can be used for analysis. For example, the trace info from ETB RAM can be used to check the CPU execution flows before crash. So we can save the tracing data from sink devices, and rely on kdump to save DDR content and uses "crash" tool to extract coresight dumping from vmcore file. This patch is to add a simple framework to support panic dump functionality; it registers panic notifier, and provide the general APIs {coresight_kdump_add|coresight_kdump_del} as helper functions so any coresight device can add itself into dump list or delete as needed. This driver provides helper function coresight_kdump_update() to update the dump buffer base address and buffer size. This function can be used by coresight driver, e.g. it can be used to save ETM meta data info at runtime and these info can be prepared pre panic happening. When kernel panic happens, the notifier iterates dump list and calls callback function to dump device specific info. The panic dump is mainly used to dump trace data so we can get to know the execution flow before the panic happens. Signed-off-by: Leo Yan --- drivers/hwtracing/coresight/Kconfig | 9 ++ drivers/hwtracing/coresight/Makefile | 1 + .../hwtracing/coresight/coresight-panic-kdump.c | 154 +++++++++++++++++++++ drivers/hwtracing/coresight/coresight-priv.h | 13 ++ include/linux/coresight.h | 7 + 5 files changed, 184 insertions(+) create mode 100644 drivers/hwtracing/coresight/coresight-panic-kdump.c -- 2.7.4 diff --git a/drivers/hwtracing/coresight/Kconfig b/drivers/hwtracing/coresight/Kconfig index ef9cb3c..4812529 100644 --- a/drivers/hwtracing/coresight/Kconfig +++ b/drivers/hwtracing/coresight/Kconfig @@ -103,4 +103,13 @@ config CORESIGHT_CPU_DEBUG properly, please refer Documentation/trace/coresight-cpu-debug.txt for detailed description and the example for usage. +config CORESIGHT_PANIC_KDUMP + bool "CoreSight Panic Kdump driver" + depends on ARM || ARM64 + help + This driver provides panic kdump functionality for CoreSight + devices. When a kernel panic happen a device supplied callback function + is used to save trace data to memory. From there we rely on kdump to extract + the trace data from kernel dump file. + endif diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile index 61db9dd..946fe19 100644 --- a/drivers/hwtracing/coresight/Makefile +++ b/drivers/hwtracing/coresight/Makefile @@ -18,3 +18,4 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o \ obj-$(CONFIG_CORESIGHT_DYNAMIC_REPLICATOR) += coresight-dynamic-replicator.o obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o +obj-$(CONFIG_CORESIGHT_PANIC_KDUMP) += coresight-panic-kdump.o diff --git a/drivers/hwtracing/coresight/coresight-panic-kdump.c b/drivers/hwtracing/coresight/coresight-panic-kdump.c new file mode 100644 index 0000000..c21d20b --- /dev/null +++ b/drivers/hwtracing/coresight/coresight-panic-kdump.c @@ -0,0 +1,154 @@ +// SPDX-License-Identifier: GPL-2.0 +// Copyright (c) 2017 Linaro Limited. +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "coresight-priv.h" + +typedef void (*coresight_cb_t)(void *data); + +/** + * struct coresight_kdump_node - Node information for dump + * @cpu: The cpu this node is affined to. + * @csdev: Handler for coresight device. + * @buf: Pointer for dump buffer. + * @buf_size: Length of dump buffer. + * @list: Hook to the list. + */ +struct coresight_kdump_node { + int cpu; + struct coresight_device *csdev; + char *buf; + unsigned int buf_size; + struct list_head list; +}; + +static DEFINE_SPINLOCK(coresight_kdump_lock); +static LIST_HEAD(coresight_kdump_list); +static struct notifier_block coresight_kdump_nb; + +int coresight_kdump_update(struct coresight_device *csdev, char *buf, + unsigned int buf_size) +{ + struct coresight_kdump_node *node = csdev->dump_node; + + if (!node) { + dev_err(&csdev->dev, "Failed to update dump node.\n"); + return -EINVAL; + } + + node->buf = buf; + node->buf_size = buf_size; + return 0; +} + +int coresight_kdump_add(struct coresight_device *csdev, int cpu) +{ + struct coresight_kdump_node *node; + unsigned long flags; + + node = kzalloc(sizeof(*node), GFP_KERNEL); + if (!node) + return -ENOMEM; + + csdev->dump_node = (void *)node; + node->cpu = cpu; + node->csdev = csdev; + + spin_lock_irqsave(&coresight_kdump_lock, flags); + list_add_tail(&node->list, &coresight_kdump_list); + spin_unlock_irqrestore(&coresight_kdump_lock, flags); + return 0; +} + +void coresight_kdump_del(struct coresight_device *csdev) +{ + struct coresight_kdump_node *node, *next; + unsigned long flags; + + spin_lock_irqsave(&coresight_kdump_lock, flags); + list_for_each_entry_safe(node, next, &coresight_kdump_list, list) { + if (node->csdev == csdev) { + list_del(&node->list); + kfree(node); + break; + } + } + spin_unlock_irqrestore(&coresight_kdump_lock, flags); +} + +static coresight_cb_t +coresight_kdump_get_cb(struct coresight_device *csdev) +{ + coresight_cb_t cb = NULL; + + switch (csdev->type) { + case CORESIGHT_DEV_TYPE_SINK: + case CORESIGHT_DEV_TYPE_LINKSINK: + cb = sink_ops(csdev)->panic_cb; + break; + case CORESIGHT_DEV_TYPE_SOURCE: + cb = source_ops(csdev)->panic_cb; + break; + case CORESIGHT_DEV_TYPE_LINK: + cb = link_ops(csdev)->panic_cb; + break; + default: + dev_info(&csdev->dev, "Unsupport panic dump\n"); + break; + } + + return cb; +} + +/** + * coresight_kdump_notify - Invoke panic dump callbacks, this is + * the main function to fulfill the panic dump. It distinguishs + * to two types: one is pre panic dump which the callback function + * handler is NULL and coresight drivers can use function + * coresight_kdump_update() to directly update dump buffer base + * address and buffer size, for this case this function does nothing + * and directly bail out; another case is for post panic dump so + * invoke callback on alive CPU. + * + * Returns: 0 on success. + */ +static int coresight_kdump_notify(struct notifier_block *nb, + unsigned long mode, void *_unused) +{ + struct coresight_kdump_node *node; + struct coresight_device *csdev; + coresight_cb_t cb; + unsigned long flags; + + spin_lock_irqsave(&coresight_kdump_lock, flags); + + list_for_each_entry(node, &coresight_kdump_list, list) { + csdev = node->csdev; + cb = coresight_kdump_get_cb(csdev); + if (cb) + cb(csdev); + } + + spin_unlock_irqrestore(&coresight_kdump_lock, flags); + return 0; +} + +static int __init coresight_kdump_init(void) +{ + int ret; + + coresight_kdump_nb.notifier_call = coresight_kdump_notify; + ret = atomic_notifier_chain_register(&panic_notifier_list, + &coresight_kdump_nb); + return ret; +} +late_initcall(coresight_kdump_init); diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h index f1d0e21d..937750e 100644 --- a/drivers/hwtracing/coresight/coresight-priv.h +++ b/drivers/hwtracing/coresight/coresight-priv.h @@ -151,4 +151,17 @@ static inline int etm_readl_cp14(u32 off, unsigned int *val) { return 0; } static inline int etm_writel_cp14(u32 off, u32 val) { return 0; } #endif +#ifdef CONFIG_CORESIGHT_PANIC_KDUMP +extern int coresight_kdump_add(struct coresight_device *csdev, int cpu); +extern void coresight_kdump_del(struct coresight_device *csdev); +extern int coresight_kdump_update(struct coresight_device *csdev, + char *buf, unsigned int buf_size); +#else +static inline int +coresight_kdump_add(struct coresight_device *csdev, int cpu) { return 0; } +static inline void coresight_kdump_del(struct coresight_device *csdev) {} +static inline int coresight_kdump_update(struct coresight_device *csdev, + char *buf, unsigned int buf_size) { return 0; } +#endif + #endif diff --git a/include/linux/coresight.h b/include/linux/coresight.h index d950dad..43e40fa 100644 --- a/include/linux/coresight.h +++ b/include/linux/coresight.h @@ -171,6 +171,7 @@ struct coresight_device { bool orphan; bool enable; /* true only if configured as part of a path */ bool activated; /* true only if a sink is part of a path */ + void *dump_node; }; #define to_coresight_device(d) container_of(d, struct coresight_device, dev) @@ -189,6 +190,7 @@ struct coresight_device { * @set_buffer: initialises buffer mechanic before a trace session. * @reset_buffer: finalises buffer mechanic after a trace session. * @update_buffer: update buffer pointers after a trace session. + * @panic_cb: hook function for panic notifier. */ struct coresight_ops_sink { int (*enable)(struct coresight_device *csdev, u32 mode); @@ -205,6 +207,7 @@ struct coresight_ops_sink { void (*update_buffer)(struct coresight_device *csdev, struct perf_output_handle *handle, void *sink_config); + void (*panic_cb)(void *data); }; /** @@ -212,10 +215,12 @@ struct coresight_ops_sink { * Operations available for links. * @enable: enables flow between iport and oport. * @disable: disables flow between iport and oport. + * @panic_cb: hook function for panic notifier. */ struct coresight_ops_link { int (*enable)(struct coresight_device *csdev, int iport, int oport); void (*disable)(struct coresight_device *csdev, int iport, int oport); + void (*panic_cb)(void *data); }; /** @@ -227,6 +232,7 @@ struct coresight_ops_link { * to the HW. * @enable: enables tracing for a source. * @disable: disables tracing for a source. + * @panic_cb: hook function for panic notifier. */ struct coresight_ops_source { int (*cpu_id)(struct coresight_device *csdev); @@ -235,6 +241,7 @@ struct coresight_ops_source { struct perf_event *event, u32 mode); void (*disable)(struct coresight_device *csdev, struct perf_event *event); + void (*panic_cb)(void *data); }; struct coresight_ops { From patchwork Thu Dec 21 08:20:13 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leo Yan X-Patchwork-Id: 122519 Delivered-To: patch@linaro.org Received: by 10.140.22.227 with SMTP id 90csp581039qgn; Thu, 21 Dec 2017 00:21:46 -0800 (PST) X-Google-Smtp-Source: ACJfBovHXegkVODnAmZ43GbYDbUVYa9QDynyDrZX5iXo++siwFujiX7xqee4fnPZNeXIawxZVW3n X-Received: by 10.84.235.2 with SMTP id o2mr9656182plk.64.1513844506095; Thu, 21 Dec 2017 00:21:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1513844506; cv=none; d=google.com; s=arc-20160816; b=H1sV8xMcBrsck33cCdVtQyJ5XFxSxAHdck9vSO1Z0R1QnXipRM//RDh5cboBhTLp5d yV3nShlqbJeptCJr8tr8uW8NBbSjs6j8vwg7GrH9O5EeYINfRhY/hO9JAX3fyyjwra29 mkkZk34zzH8zSDQ+drTQGH7bvBEyqbH7ZLd8sSh7jp9vBbdIx5rEjWsEA5luZTuD6REw XyRYmm99meK4B2g2eavMZksiCjNiFWqqhmToNT7ordxzzIGC819daFzk3unMbQgqJvTC oD0nwGS8PPpO7TM3DmnEsvg9m7iV/CARwavKA+Yg1rDtfqg1Q3PBsY+MfSFeNCkHUVO7 8VyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=/eTpv8iA5Al+T360+/ZTh3hwOR46+gjkKrw3OpJ/WGI=; b=F6eTv0wnYPRQMgKFRytrq1NEadmfZSaoFCApIlWN2bPPsvvzXWlaX6fzw61XG7hb8R JbDakCM2rro1x35vcI7uWavegxnMepXJfveejms2oKf+tr0MajxLlWcmmmN1wblF636q Yj7wbzyMvnzcfWEytbSNWg40k3mtbmpecKXUdtvnnL1qWWcFRnDIyzXmRTcjQxiR30T/ 0sgz7L8Wk9fuqIGwu/fCUpi5ItkjH5Ki+3m7RrA9SMD7imoKZu8cpqECSTMbcCNwsvTB Ru+fpf3L4tC3nAr8M0jktCxTdmwxOlONjh0xuRScDWOyyiopFPD2IMT4+xx+NdwK91YL VvLQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=DU5RMvGs; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p7si15113413pll.96.2017.12.21.00.21.45; Thu, 21 Dec 2017 00:21:46 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=DU5RMvGs; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751976AbdLUIVl (ORCPT + 28 others); Thu, 21 Dec 2017 03:21:41 -0500 Received: from mail-pg0-f67.google.com ([74.125.83.67]:43989 "EHLO mail-pg0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751781AbdLUIU6 (ORCPT ); Thu, 21 Dec 2017 03:20:58 -0500 Received: by mail-pg0-f67.google.com with SMTP id b18so12975642pgv.10 for ; Thu, 21 Dec 2017 00:20:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=/eTpv8iA5Al+T360+/ZTh3hwOR46+gjkKrw3OpJ/WGI=; b=DU5RMvGs/cms3WgP3IKWfxsyXumEnJ5e+osvE/TBSWjb8gWFpC4IlBjQX+zLlJN6q0 DSs1rRRxQ7jdCotYwn2+iO6Rzl72YFyDyUU+8sUj4Ted9/dN4YKBYM87nxi5dMKAsJeH uT2XUmUDSVgFmXT6w7AFv5RhFGFntOU2vFL+M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=/eTpv8iA5Al+T360+/ZTh3hwOR46+gjkKrw3OpJ/WGI=; b=VlmKq+gAiTEYjS77bh4e6Ze5VlYVudx/ROaj2lpy1uq5EApsUclUaMa6RFMtju1430 1+p1mJQNxjvxWspIx+z9vapjEXDi/RXSWcLk0JS5gpS1sbN4frSMoKLihjsVnGkQ5sFr CB+Im3GBMMX0QHwXYEJrZXz0RZ+dmFseRJB+PhaehfwZi8+ycwiiQyS7zFTBLoxAPRfG 9ZWVduPjqF7Ud3ElMpHkJDYjje5KG65VgtNjFpFVSC60YjIeZu2PgMur6x/zToakKj98 G6z8njkuMJG8OxyCTliXJdUYswfS5IVsXi/mJtbiu0ZBvypCk7nmw8VWnqy3KD5s0HyU fjQg== X-Gm-Message-State: AKGB3mIZi/LbTsoPdDC2s0XTDpRbn++CXFnyQuojbqEg2PxybZsA+nV0 jkDFeYu7JVd0n8TgH5iukvZklw== X-Received: by 10.99.121.72 with SMTP id u69mr8936876pgc.419.1513844458094; Thu, 21 Dec 2017 00:20:58 -0800 (PST) Received: from localhost.localdomain (li159-223.members.linode.com. [173.230.149.223]) by smtp.gmail.com with ESMTPSA id r86sm43699720pfk.114.2017.12.21.00.20.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Dec 2017 00:20:56 -0800 (PST) From: Leo Yan To: Jonathan Corbet , Mathieu Poirier , Greg Kroah-Hartman , Will Deacon , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, coresight@lists.linaro.org Cc: Leo Yan Subject: [PATCH v3 4/6] coresight: tmc: Hook callback for panic kdump Date: Thu, 21 Dec 2017 16:20:13 +0800 Message-Id: <1513844415-11427-5-git-send-email-leo.yan@linaro.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1513844415-11427-1-git-send-email-leo.yan@linaro.org> References: <1513844415-11427-1-git-send-email-leo.yan@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Since the panic kdump functionality has been ready, this patch is to hook panic callback function for ETB/ETF. Since the driver data structure has allocated buffer when the session started, so simply save ETB/ETF trace data into the buffer when panic happens and update related info into dump node. Signed-off-by: Leo Yan --- drivers/hwtracing/coresight/coresight-tmc-etf.c | 29 +++++++++++++++++++++++++ 1 file changed, 29 insertions(+) -- 2.7.4 diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c b/drivers/hwtracing/coresight/coresight-tmc-etf.c index e2513b7..f823464 100644 --- a/drivers/hwtracing/coresight/coresight-tmc-etf.c +++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c @@ -504,6 +504,34 @@ static void tmc_update_etf_buffer(struct coresight_device *csdev, CS_LOCK(drvdata->base); } +static void tmc_panic_cb(void *data) +{ + struct coresight_device *csdev = (struct coresight_device *)data; + struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent); + unsigned long flags; + + if (WARN_ON_ONCE(drvdata->config_type != TMC_CONFIG_TYPE_ETB && + drvdata->config_type != TMC_CONFIG_TYPE_ETF)) + return; + + if (drvdata->mode == CS_MODE_DISABLED) + return; + + spin_lock_irqsave(&drvdata->spinlock, flags); + + CS_UNLOCK(drvdata->base); + + tmc_flush_and_stop(drvdata); + tmc_etb_dump_hw(drvdata); + + CS_LOCK(drvdata->base); + + /* Update buffer info for panic dump */ + coresight_kdump_update(csdev, drvdata->buf, drvdata->len); + + spin_unlock_irqrestore(&drvdata->spinlock, flags); +} + static const struct coresight_ops_sink tmc_etf_sink_ops = { .enable = tmc_enable_etf_sink, .disable = tmc_disable_etf_sink, @@ -512,6 +540,7 @@ static const struct coresight_ops_sink tmc_etf_sink_ops = { .set_buffer = tmc_set_etf_buffer, .reset_buffer = tmc_reset_etf_buffer, .update_buffer = tmc_update_etf_buffer, + .panic_cb = tmc_panic_cb, }; static const struct coresight_ops_link tmc_etf_link_ops = { From patchwork Thu Dec 21 08:20:14 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leo Yan X-Patchwork-Id: 122517 Delivered-To: patch@linaro.org Received: by 10.140.22.227 with SMTP id 90csp580556qgn; Thu, 21 Dec 2017 00:21:12 -0800 (PST) X-Google-Smtp-Source: ACJfBosMSQBF7lGM9OGx6t+gcwChgRHfxlnBnsyE5BQBw06Wp2UG+WcsI9LkFxUzEzUv77x1ZAwi X-Received: by 10.98.153.221 with SMTP id t90mr9697729pfk.210.1513844472461; Thu, 21 Dec 2017 00:21:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1513844472; cv=none; d=google.com; s=arc-20160816; b=yRgp/xD19penojeFD+B5GpNx4zZHSrfOamKvk6JZakqGSpxkAoW2aqu0rNd6g0EecG PqqnjnIlT+SzVmd8FslT9i/ETr3SMJMHaRAOU/k9IcJ46oneQ0X6iA6L2UZLDbvYQoMO tCLD0X0NMeI3/ISVDQ8o8l2+R/uaJOrWeG2AC+imyG3RX/FxA9ijxdggNEtFm/W34Xp5 8O1Za6yUaNabYBhjgwTV3NITA8A4O3/kOxPyA+lvRkcDWUVfHWU7N2klN1AmSt9RCB6S aYO1QadIviQ9PD4UeFDPdryfUhia/iyF0sS+1PYEYIc1oo5hCjl7tn7d/EoorH0bdsp0 l4yQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=VrQnCBWyYC/bWHHsGYRdCSdNpGE6DgLe9rHXJv0twrw=; b=wk3FyRaqBjBN0loUIM2NqHpHjuZynXBe/Oka7MjFIXuJgSDir5xA/QViaICguIktx9 gY2H4SlqJAnVmPNjPIF53V4rig2hrBgMxPOIe5Og3x/BGPddrhE3E3Pt0us2gg5bg/H7 FZzKWnZESrwF0zJYwXH8/mzRAtKXLOOnk5LZ7a3de4HTZMqM7XXrcXCiZgKp1VoO6dSy GXmfSNtnHScG5X4SM6nLegpvZBmUl5mmpVu8cuyfaWixM/LRkWy1ZH6obRfJq0WmfgTY V6nEUMX5WL1cNRABmKu1w31xr5Gw0KUREJzos31t/O5puspyxi9jVKTp+bTA2G1wV7wZ Tb6Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=QmVAUYjD; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 8si14568944pfo.144.2017.12.21.00.21.12; Thu, 21 Dec 2017 00:21:12 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=QmVAUYjD; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751907AbdLUIVK (ORCPT + 28 others); Thu, 21 Dec 2017 03:21:10 -0500 Received: from mail-pl0-f67.google.com ([209.85.160.67]:44596 "EHLO mail-pl0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751685AbdLUIVE (ORCPT ); Thu, 21 Dec 2017 03:21:04 -0500 Received: by mail-pl0-f67.google.com with SMTP id n13so10586760plp.11 for ; Thu, 21 Dec 2017 00:21:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=VrQnCBWyYC/bWHHsGYRdCSdNpGE6DgLe9rHXJv0twrw=; b=QmVAUYjDqqIl4lYzl8syiIDmJZ1lFIeSkbucwsCySdmT1KvfLgaCN4Dw8/DQzgRA/O l49QP5pKxusxYxhXFyVch5zwpfYRk9FwqAwsMQHUUJu561WPJ+XLOY24iJ6Ltn5gbhyg 6YtQ9gLARlBhJk3t4jPvya15yZTPYW4ILdgSw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=VrQnCBWyYC/bWHHsGYRdCSdNpGE6DgLe9rHXJv0twrw=; b=BqtSoRHIv4hEGgWooxeoPFpzITTNHcNaxkj7s8UtXEygxrERa0AwnNcNdBnoI+zBo3 1m2d1srMegZxbx+5JJFFQD6/c+NVfaMDr2K+4S5TYn2gPX+A+i1E+l1wHzYPTifiq/a8 ZAA9zVFFzO8Fq5smJfO9QeFzLjsccmPNJI061pvFD964L/nTnO0QUxifK/LR8LXdX4+T /GJS1PaNq/OcKs4XvX2c2c2HDcuzn6QuluZTb8T/D1/XiHlc7ALboIz9z3/YWc9F7bjB WRq98eeMRvyk43JttLigVPCYkHohzgSMPsz+Sj0u9dY2fx22gtQbgJdmwqLGg1DejMLo vOBA== X-Gm-Message-State: AKGB3mKgGMpZbEc6j5Sk4enH1IocE6SJQbCD5+OKMy1zPoG1wenVFZ4+ kYcHe4n1rXOjnwLOdrS7FVbs4Eb0Xh8= X-Received: by 10.159.247.134 with SMTP id e6mr9481274pls.279.1513844463689; Thu, 21 Dec 2017 00:21:03 -0800 (PST) Received: from localhost.localdomain (li159-223.members.linode.com. [173.230.149.223]) by smtp.gmail.com with ESMTPSA id r86sm43699720pfk.114.2017.12.21.00.20.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Dec 2017 00:21:02 -0800 (PST) From: Leo Yan To: Jonathan Corbet , Mathieu Poirier , Greg Kroah-Hartman , Will Deacon , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, coresight@lists.linaro.org Cc: Leo Yan Subject: [PATCH v3 5/6] coresight: Add and delete sink callback for panic kdump list Date: Thu, 21 Dec 2017 16:20:14 +0800 Message-Id: <1513844415-11427-6-git-send-email-leo.yan@linaro.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1513844415-11427-1-git-send-email-leo.yan@linaro.org> References: <1513844415-11427-1-git-send-email-leo.yan@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org If the sink device has panic kdump callback, this means the sink device wants to save tracing data for panic happening. This commit adds node into panic kdump list when the sink device is enabled, and delete node when the sink device is disabled. Signed-off-by: Leo Yan --- drivers/hwtracing/coresight/coresight.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) -- 2.7.4 diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c index 389c4ba..56798b1 100644 --- a/drivers/hwtracing/coresight/coresight.c +++ b/drivers/hwtracing/coresight/coresight.c @@ -146,6 +146,14 @@ static int coresight_enable_sink(struct coresight_device *csdev, u32 mode) if (ret) return ret; } + + /* Add into panic kdump list */ + if (sink_ops(csdev)->panic_cb) { + ret = coresight_kdump_add(csdev, 0); + if (ret) + return ret; + } + csdev->enable = true; } @@ -157,6 +165,10 @@ static int coresight_enable_sink(struct coresight_device *csdev, u32 mode) static void coresight_disable_sink(struct coresight_device *csdev) { if (atomic_dec_return(csdev->refcnt) == 0) { + /* Delete from panic kdump list */ + if (sink_ops(csdev)->panic_cb) + coresight_kdump_del(csdev); + if (sink_ops(csdev)->disable) { sink_ops(csdev)->disable(csdev); csdev->enable = false; From patchwork Thu Dec 21 08:20:15 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leo Yan X-Patchwork-Id: 122518 Delivered-To: patch@linaro.org Received: by 10.140.22.227 with SMTP id 90csp580736qgn; Thu, 21 Dec 2017 00:21:24 -0800 (PST) X-Google-Smtp-Source: ACJfBotxK1sht8J7BsapCXI0O60HrnrnqSMHohHepEDSH9+RftK25+xjh8gN9jKriSpr9KZjsgD+ X-Received: by 10.101.82.137 with SMTP id y9mr4063096pgp.325.1513844484432; Thu, 21 Dec 2017 00:21:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1513844484; cv=none; d=google.com; s=arc-20160816; b=OkWull8xO620i1F5ebuv2il16mzzfpI+IcVqteAPcsP3zapE0m6T/xEyT3F8OorpUb PhDdcS6SB1PsRAg4mJoqJ3ucN0D8fI29OBkfMau6KqyjrBOfsuu2Z8vLgThNxIT/HZ0t 68KPIFyTMwxNsy8SAo7nsj3+oBLGHYyIB7moIY/ZW9ULJB2CNgI164BdYeQn7qsbOqo2 4XMs5ANGEOYjBmYpPlHZ0gH7dORaysuto9dMsBf8b15hu1iqLn/HdJEu8X7klYrCaiHA Mb/CQD5VZDgka3S5FYe0TVNyiLEP8VuexDg7+LAC0bTyO7rYHrUEWKhQMZWf68/8aEHg 7+Iw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=hVcw3xdLS6WeFuwfw5o1/9kGrkGHKX+BEls7BbqyzX0=; b=M+lDhJfRt16zkJ0ZEMQFU9wt0FxbwBj6rYgFJnqG4ZTayiUi0+Qk8NZI6SWa7p/3p4 QoduccM+g27Hi4oD+/xg4cIeQMRzZSyfY3fVNpI1KmZrkmit1/xUpyV7RMaduOkcI1JT t4A+KdxdNFlyt963DXNoxOvQwMov1CLy4szvYhwRm8qSaHje95zFcHNQLtm9r42Lcmun gHne18YgnN9eW3svXrErCEDSPd1iUElIkVAfHh21bLoEupDXRy4mrUx/V/7OfvPwXkWY QImJk04Mv8rJKrOnneVbQqEX27GRMGgofgDjXSeBlSQ+Vn2ABxo5Y8/EdgHXgyCrAMjJ baxg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=ElIyeibX; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k6si13211470pgt.332.2017.12.21.00.21.24; Thu, 21 Dec 2017 00:21:24 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=ElIyeibX; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751973AbdLUIVT (ORCPT + 28 others); Thu, 21 Dec 2017 03:21:19 -0500 Received: from mail-pg0-f67.google.com ([74.125.83.67]:38181 "EHLO mail-pg0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751868AbdLUIVJ (ORCPT ); Thu, 21 Dec 2017 03:21:09 -0500 Received: by mail-pg0-f67.google.com with SMTP id f12so12984361pgo.5 for ; Thu, 21 Dec 2017 00:21:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=hVcw3xdLS6WeFuwfw5o1/9kGrkGHKX+BEls7BbqyzX0=; b=ElIyeibXgKizq9nJocqY9T9N+wa89tyvBSe4KbllXvZXgfvELn+UX1TEFfEFPSJmsG LP1UCcC4DWG5/vrGgjOtJ1AAQ6jx+D4IOmWh/35TPbMXt5eNVKdiaomx/jhxqqOPnVzV 9xYGVDlUiNt2CelGjWg9jLVbVET/MC1gVXixo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=hVcw3xdLS6WeFuwfw5o1/9kGrkGHKX+BEls7BbqyzX0=; b=aO9hgRyyyP9y9aIJEtb5u6iziU2d5bu2sMUcmhPDwQH6BykYn/ATDu0tA4cuefZCCj Vywr/CQ3UQnjgEmODbc57M499e5Ssjwmh6s4V4VNfokr1rulaFkPtHA5sPK6d5FcUP9V JkIBjEUs2b6i5R5qUK3DnLYMqCJUmaPxzePDHcArvFVuTBpz09i/l/QHOpaW5X1M7May xQHEbLpAF/1tfpp8LteZAbDgt+NeZHvhQ0KaBWvIQ9y+OG/zReTzQROEY6auK37oyWde n5VNhASk4mUR1RdfXUzxKgqe4jfMMKgYyt3vn+4qToRt0/YBd9KTFcnFykHEvDqCfs+v p2mQ== X-Gm-Message-State: AKGB3mIVSKS1YC4rpWnqeq9evrnxG1wE9FDX3Yfgbmb4rZeNbNmdM2U7 5NHi39J4BZ1kxD6b7RE304QjNw== X-Received: by 10.98.138.17 with SMTP id y17mr9775299pfd.122.1513844468283; Thu, 21 Dec 2017 00:21:08 -0800 (PST) Received: from localhost.localdomain (li159-223.members.linode.com. [173.230.149.223]) by smtp.gmail.com with ESMTPSA id r86sm43699720pfk.114.2017.12.21.00.21.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Dec 2017 00:21:07 -0800 (PST) From: Leo Yan To: Jonathan Corbet , Mathieu Poirier , Greg Kroah-Hartman , Will Deacon , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, coresight@lists.linaro.org Cc: Leo Yan Subject: [PATCH v3 6/6] coresight: etm4x: Support panic kdump Date: Thu, 21 Dec 2017 16:20:15 +0800 Message-Id: <1513844415-11427-7-git-send-email-leo.yan@linaro.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1513844415-11427-1-git-send-email-leo.yan@linaro.org> References: <1513844415-11427-1-git-send-email-leo.yan@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ETMv4 hardware information and configuration needs to be saved as metadata; these metadata should be compatible with tool 'perf' and can be used for tracing data analysis. ETMv4 usually works as tracer per CPU, we cannot wait to gather ETM info after the CPU has been panic and cannot execute dump operations for itself; so should gather metadata when the corresponding CPU is alive. Since values in TRCIDR{0, 1, 2, 8} and TRCAUTHSTATUS are read-only and won't change at the runtime. Those registers value are filled when tracers are instantiated. The configuration and control registers TRCCONFIGR and TRCTRACEIDR are dynamically configured, we record their value when enabling coresight path. When operating from sysFS tracer these two registers are recorded in etm4_enable_sysfs() and add kdump node into list, and remove the kdump node in etm4_disable_sysfs(). When operating from perf, etm_setup_aux() adds all tracers to the dump list and etm4_enable_perf() is used to record configuration registers and update dump buffer info, this can avoid unnecessary list addition and deletion operations. Removal of the tracers from the dump list is done in function free_event_data(). Suggested-by: Mathieu Poirier Signed-off-by: Leo Yan --- drivers/hwtracing/coresight/coresight-etm-perf.c | 12 +++++++++++- drivers/hwtracing/coresight/coresight-etm4x.c | 23 +++++++++++++++++++++++ drivers/hwtracing/coresight/coresight-etm4x.h | 15 +++++++++++++++ 3 files changed, 49 insertions(+), 1 deletion(-) -- 2.7.4 diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c index 8a0ad77..fec779b 100644 --- a/drivers/hwtracing/coresight/coresight-etm-perf.c +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c @@ -137,6 +137,12 @@ static void free_event_data(struct work_struct *work) } for_each_cpu(cpu, mask) { + struct coresight_device *csdev; + + csdev = per_cpu(csdev_src, cpu); + if (csdev) + coresight_kdump_del(csdev); + if (!(IS_ERR_OR_NULL(event_data->path[cpu]))) coresight_release_path(event_data->path[cpu]); } @@ -195,7 +201,7 @@ static void etm_free_aux(void *data) static void *etm_setup_aux(int event_cpu, void **pages, int nr_pages, bool overwrite) { - int cpu; + int cpu, ret; cpumask_t *mask; struct coresight_device *sink; struct etm_event_data *event_data = NULL; @@ -238,6 +244,10 @@ static void *etm_setup_aux(int event_cpu, void **pages, event_data->path[cpu] = coresight_build_path(csdev, sink); if (IS_ERR(event_data->path[cpu])) goto err; + + ret = coresight_kdump_add(csdev, cpu); + if (ret) + goto err; } if (!sink_ops(sink)->alloc_buffer) diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c index cf364a5..cbde398 100644 --- a/drivers/hwtracing/coresight/coresight-etm4x.c +++ b/drivers/hwtracing/coresight/coresight-etm4x.c @@ -258,10 +258,19 @@ static int etm4_enable_perf(struct coresight_device *csdev, static int etm4_enable_sysfs(struct coresight_device *csdev) { struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent); + struct etmv4_config *config = &drvdata->config; + struct etmv4_metadata *metadata = &drvdata->metadata; int ret; spin_lock(&drvdata->spinlock); + /* Update meta data and add into kdump list */ + metadata->trcconfigr = config->cfg; + metadata->trctraceidr = drvdata->trcid; + + coresight_kdump_add(csdev, drvdata->cpu); + coresight_kdump_update(csdev, (char *)metadata, sizeof(*metadata)); + /* * Executing etm4_enable_hw on the cpu whose ETM is being enabled * ensures that register writes occur when cpu is powered. @@ -384,6 +393,9 @@ static void etm4_disable_sysfs(struct coresight_device *csdev) */ smp_call_function_single(drvdata->cpu, etm4_disable_hw, drvdata, 1); + /* Delete from kdump list */ + coresight_kdump_del(csdev); + spin_unlock(&drvdata->spinlock); cpus_read_unlock(); @@ -438,6 +450,7 @@ static void etm4_init_arch_data(void *info) u32 etmidr4; u32 etmidr5; struct etmv4_drvdata *drvdata = info; + struct etmv4_metadata *metadata = &drvdata->metadata; /* Make sure all registers are accessible */ etm4_os_unlock(drvdata); @@ -590,6 +603,16 @@ static void etm4_init_arch_data(void *info) drvdata->nrseqstate = BMVAL(etmidr5, 25, 27); /* NUMCNTR, bits[30:28] number of counters available for tracing */ drvdata->nr_cntr = BMVAL(etmidr5, 28, 30); + + /* Update metadata */ + metadata->magic = ETM4_METADATA_MAGIC; + metadata->cpu = drvdata->cpu; + metadata->trcidr0 = readl_relaxed(drvdata->base + TRCIDR0); + metadata->trcidr1 = readl_relaxed(drvdata->base + TRCIDR1); + metadata->trcidr2 = readl_relaxed(drvdata->base + TRCIDR2); + metadata->trcidr8 = readl_relaxed(drvdata->base + TRCIDR8); + metadata->trcauthstatus = readl_relaxed(drvdata->base + TRCAUTHSTATUS); + CS_LOCK(drvdata->base); } diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h b/drivers/hwtracing/coresight/coresight-etm4x.h index b3b5ea7..08dc8b7 100644 --- a/drivers/hwtracing/coresight/coresight-etm4x.h +++ b/drivers/hwtracing/coresight/coresight-etm4x.h @@ -198,6 +198,20 @@ #define ETM_EXLEVEL_NS_HYP BIT(14) #define ETM_EXLEVEL_NS_NA BIT(15) +#define ETM4_METADATA_MAGIC 0x4040404040404040ULL + +struct etmv4_metadata { + u64 magic; + u64 cpu; + u64 trcconfigr; + u64 trctraceidr; + u64 trcidr0; + u64 trcidr1; + u64 trcidr2; + u64 trcidr8; + u64 trcauthstatus; +}; + /** * struct etmv4_config - configuration information related to an ETMv4 * @mode: Controls various modes supported by this ETM. @@ -393,6 +407,7 @@ struct etmv4_drvdata { bool atbtrig; bool lpoverride; struct etmv4_config config; + struct etmv4_metadata metadata; }; /* Address comparator access types */