From patchwork Fri Mar 30 03:15:19 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leo Yan X-Patchwork-Id: 132578 Delivered-To: patch@linaro.org Received: by 10.46.84.29 with SMTP id i29csp2530622ljb; Thu, 29 Mar 2018 20:16:02 -0700 (PDT) X-Google-Smtp-Source: AIpwx487cJKhNMvnOhIIgkWvGZ7VbZlqZ7wzhZCgunuxKF8+ltNQCbEPS/3eBoNH2dte3uEujITu X-Received: by 2002:a17:902:b101:: with SMTP id q1-v6mr11055207plr.3.1522379761928; Thu, 29 Mar 2018 20:16:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522379761; cv=none; d=google.com; s=arc-20160816; b=0meeSVenUl0JNPBFAx/GIXLD1C4IzqoEBddQz+Bpajh1YcFqhvu9zQbG4BCp3R82XX 5Trp5/YLzzPiPCxpNK+EdIboNm6NHgomhtH0JxC+LEbeNv6qLVH+nSWHQG2ExLl+Sx/M 7mtQ38iX90iqpgQ/+VaNUXfXUJOF7lUaEuVbUMhMxu8S+utFsAdJeeKBHMoQPa4IH6O3 AW8Kp9d7W7ac/JCAo82ZRBE/Y4F0Khkf0rT/6mWQkLY1DvGxp5fr6dh9F+9AcayKHiB+ Ib1g8mLvtk9zru+MdzOy//cPdGyTDQBNN2bHBSpFijsz8QTPAAgQ5ABvbjpEC9ZB+/tV 4MjQ== 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=pJB+Pz9Uw+xSLoAtMuOxEwaBMYgEMWpWLNwwkfSaIF4=; b=rsQtzDCzrpGDEwtE+dWDicuRdnmgmMuaU4+ayYoiJA1ht8rmytVm+p5J4coByVEhAq bP9tj7gVSTxv8Ui/f1bwvI40nQA2brPhnVNRn7j3hs3fKtYKDzbZTFw9mW02O7PaEnfv QUoWf/t6W0/Xj0y6YVBa2WZxAWP4ZZnYlshDtni5rTkrXaesJPe9NcgIzO2KY1pC2V5w KXmg/UYI88c7GgLmAmO6f5FCrJ8V7e4j1cF4UTYXRZmcDX6ubZQ1aex6RmGjhJzAuogP oVvz/XqZiF/8wXsQFzQRJ6jag5xuOfQWsw7G3sNFdaad9/ax/TnR9i6qf7c3Aqeoxmq6 pquw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=hX6Vub2r; 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 u2-v6si7496411plm.671.2018.03.29.20.16.01; Thu, 29 Mar 2018 20:16:01 -0700 (PDT) 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=hX6Vub2r; 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 S1752766AbeC3DP7 (ORCPT + 29 others); Thu, 29 Mar 2018 23:15:59 -0400 Received: from mail-wm0-f45.google.com ([74.125.82.45]:53945 "EHLO mail-wm0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752728AbeC3DPy (ORCPT ); Thu, 29 Mar 2018 23:15:54 -0400 Received: by mail-wm0-f45.google.com with SMTP id p9so13677137wmc.3 for ; Thu, 29 Mar 2018 20:15:53 -0700 (PDT) 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=pJB+Pz9Uw+xSLoAtMuOxEwaBMYgEMWpWLNwwkfSaIF4=; b=hX6Vub2r2cc/ZWoXchmYq/VcZm867J5wfx8IAlUhIxc3mN1tufxaQ36zpb4yCPCzXH z/p8XzykSXdy5ddnMUP1JsOj58bAxmRftCkLS8GvHCiBkwktFdFFBJKXP/XoGKQggi6Y 5RLh7jDzZIUeqvXE9hwOAZLF/HBlzHEl8jZDY= 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=pJB+Pz9Uw+xSLoAtMuOxEwaBMYgEMWpWLNwwkfSaIF4=; b=Jk4oqaRNuaqf/rLqCSXdKOTDWGESpAHw+wjLm/7vqsQAgL0F6H1J5MKj2Vw8B0omVC rwxi4rZ9hp/dz3wNkGW+fVubSJXa0DuyO3eEPC8GJokJACnxJOMedNthLD0Z4CuHKabZ oHETg+NuUoBplphEmtIsNNO3Uk7tZrNmXm64t3tT7BGMNnFjSz7XkOTlQZvFL1Yj3Gm1 pvPJslmue2YT+SIZgT3ID0+Xyk3pf+r3PhdiydGY3yQkCV5qMWSMAtu/a9NTaTD2+7a4 HNkqlXozOT1AYpRJJ5Ynud/twMX/KN4JTF/kb5K5xtIGbwfv+0w/qh3h/klAP1qARWTK rr+g== X-Gm-Message-State: AElRT7GjhThQ5OkqsbX5z+UuMNjUbjV0FOXzjh6LGlj6JKJt+aUchlhO g42mXDM3yDU1cduVv8ah7LySLw== X-Received: by 10.28.192.7 with SMTP id q7mr473289wmf.44.1522379751833; Thu, 29 Mar 2018 20:15:51 -0700 (PDT) Received: from localhost.localdomain (li622-172.members.linode.com. [212.71.249.172]) by smtp.gmail.com with ESMTPSA id z9sm12798903wrz.4.2018.03.29.20.15.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 29 Mar 2018 20:15:50 -0700 (PDT) From: Leo Yan To: Jonathan Corbet , Mathieu Poirier , Greg Kroah-Hartman , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, coresight@lists.linaro.org, Kim Phillips , Mike Leach Cc: Leo Yan Subject: [PATCH v4 1/6] doc: Add Coresight documentation directory Date: Fri, 30 Mar 2018 11:15:19 +0800 Message-Id: <1522379724-30648-2-git-send-email-leo.yan@linaro.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1522379724-30648-1-git-send-email-leo.yan@linaro.org> References: <1522379724-30648-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 easy management and friendly adding more Coresight documentation, this commit creates a new directory: Documentation/trace/coresight. This commit also moves Coresight related docs into the 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 | 383 --------------------- .../trace/coresight/coresight-cpu-debug.txt | 187 ++++++++++ Documentation/trace/coresight/coresight.txt | 383 +++++++++++++++++++++ MAINTAINERS | 4 +- 5 files changed, 572 insertions(+), 572 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 6f0120c..0000000 --- a/Documentation/trace/coresight.txt +++ /dev/null @@ -1,383 +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 - - -Using perf tools ----------------- - -perf can be used to record and analyze trace of programs. - -Execution can be recorded using 'perf record' with the cs_etm event, -specifying the name of the sink to record to, e.g: - - perf record -e cs_etm/@20070000.etr/u --per-thread - -The 'perf report' and 'perf script' commands can be used to analyze execution, -synthesizing instruction and branch events from the instruction trace. -'perf inject' can be used to replace the trace data with the synthesized events. -The --itrace option controls the type and frequency of synthesized events -(see perf documentation). - -Note that only 64-bit programs are currently supported - further work is -required to support instruction decode of 32-bit Arm programs. - - -Generating coverage files for Feedback Directed Optimization: AutoFDO ---------------------------------------------------------------------- - -'perf inject' accepts the --itrace option in which case tracing data is -removed and replaced with the synthesized events. e.g. - - perf inject --itrace --strip -i perf.data -o perf.data.new - -Below is an example of using ARM ETM for autoFDO. It requires autofdo -(https://github.com/google/autofdo) and gcc version 5. The bubble -sort example is from the AutoFDO tutorial (https://gcc.gnu.org/wiki/AutoFDO/Tutorial). - - $ gcc-5 -O3 sort.c -o sort - $ taskset -c 2 ./sort - Bubble sorting array of 30000 elements - 5910 ms - - $ perf record -e cs_etm/@20070000.etr/u --per-thread taskset -c 2 ./sort - Bubble sorting array of 30000 elements - 12543 ms - [ perf record: Woken up 35 times to write data ] - [ perf record: Captured and wrote 69.640 MB perf.data ] - - $ perf inject -i perf.data -o inj.data --itrace=il64 --strip - $ create_gcov --binary=./sort --profile=inj.data --gcov=sort.gcov -gcov_version=1 - $ gcc-5 -O3 -fauto-profile=sort.gcov sort.c -o sort_autofdo - $ taskset -c 2 ./sort_autofdo - Bubble sorting array of 30000 elements - 5806 ms 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..6f0120c --- /dev/null +++ b/Documentation/trace/coresight/coresight.txt @@ -0,0 +1,383 @@ + 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 + + +Using perf tools +---------------- + +perf can be used to record and analyze trace of programs. + +Execution can be recorded using 'perf record' with the cs_etm event, +specifying the name of the sink to record to, e.g: + + perf record -e cs_etm/@20070000.etr/u --per-thread + +The 'perf report' and 'perf script' commands can be used to analyze execution, +synthesizing instruction and branch events from the instruction trace. +'perf inject' can be used to replace the trace data with the synthesized events. +The --itrace option controls the type and frequency of synthesized events +(see perf documentation). + +Note that only 64-bit programs are currently supported - further work is +required to support instruction decode of 32-bit Arm programs. + + +Generating coverage files for Feedback Directed Optimization: AutoFDO +--------------------------------------------------------------------- + +'perf inject' accepts the --itrace option in which case tracing data is +removed and replaced with the synthesized events. e.g. + + perf inject --itrace --strip -i perf.data -o perf.data.new + +Below is an example of using ARM ETM for autoFDO. It requires autofdo +(https://github.com/google/autofdo) and gcc version 5. The bubble +sort example is from the AutoFDO tutorial (https://gcc.gnu.org/wiki/AutoFDO/Tutorial). + + $ gcc-5 -O3 sort.c -o sort + $ taskset -c 2 ./sort + Bubble sorting array of 30000 elements + 5910 ms + + $ perf record -e cs_etm/@20070000.etr/u --per-thread taskset -c 2 ./sort + Bubble sorting array of 30000 elements + 12543 ms + [ perf record: Woken up 35 times to write data ] + [ perf record: Captured and wrote 69.640 MB perf.data ] + + $ perf inject -i perf.data -o inj.data --itrace=il64 --strip + $ create_gcov --binary=./sort --profile=inj.data --gcov=sort.gcov -gcov_version=1 + $ gcc-5 -O3 -fauto-profile=sort.gcov sort.c -o sort_autofdo + $ taskset -c 2 ./sort_autofdo + Bubble sorting array of 30000 elements + 5806 ms diff --git a/MAINTAINERS b/MAINTAINERS index 205c8fc..7ee1fdc 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1331,8 +1331,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 Fri Mar 30 03:15:20 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Leo Yan X-Patchwork-Id: 132583 Delivered-To: patch@linaro.org Received: by 10.46.84.29 with SMTP id i29csp2531506ljb; Thu, 29 Mar 2018 20:17:19 -0700 (PDT) X-Google-Smtp-Source: AIpwx4//DxPHZL/+UqjKZZXIFuFn6CMzOEDB/kXCJ6NBGYZiOXzjiYNkIsvfgfJULSU/spgD5Lcj X-Received: by 10.99.140.87 with SMTP id q23mr7316827pgn.258.1522379839740; Thu, 29 Mar 2018 20:17:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522379839; cv=none; d=google.com; s=arc-20160816; b=mQVljn1aNQG6W9/69614GUAafX2MsbUIuj4z8OaKHQ3353k57b1gped7/ySs3D9oA1 VBjf/uFZR/z92b+H4G5s4yS+fM1k40URWfbGioG1Rhd9YMJoPNAVEHDr4Gg2wsN2W1TZ lUJM6AqoO3CqYeA+UVL1Ko/Q10iZlvcfuidQfPejg9VLe52OWh7hgpBh7iEWpH5PT1Fl qidINHaIWXZt5rsjeQecE1i0Unj3gV/7fEAYJW8nc/pNdhIyNsHgifsFA/ZeZNRtDkMP uODgDvqghApI01JUJmhGfGAVSWuJ6yzYnKK3RvG7Af3iqq8VP2zLEQXk7uBGu5ILVBQB eKGQ== 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=MqNmyguGfYhu4/E+EGeRniZSAKHdV2m4kZR7MbrMg1Y=; b=CpVtTauSLIVB30SCdNU95vYSvdT7xYRTdZlP7ZMhYWXvnTa7ddPau/MHBSBOCs7YAE P1A095oPdUPm7kvghseeRGs0vFNyf1tIDdD1EHy6zyQjNJk/tIJsYidDcMa4x32SFI08 /QXe/to1latzOD7C7zyAXZ+us5H6i6m4vZGFgCBng+a/tQZFGY/KDzGj/r1D7H06dTBK MeRAOvZk6oShNzvNh8KyAGwtU/rpwZvyGJvApaEqPqu2MeaLk3MFg7pRDJ7Os/j0NO8y 8ducg/Fk+lvIS7HIYQRvZfos5bjiWd6WE2/Z2aheBm55MZNtp0iEfD/+FvPUI5hvC6S4 5RBg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=jBkzzMQB; 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 o5-v6si7512908plh.432.2018.03.29.20.17.19; Thu, 29 Mar 2018 20:17:19 -0700 (PDT) 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=jBkzzMQB; 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 S1752970AbeC3DRO (ORCPT + 29 others); Thu, 29 Mar 2018 23:17:14 -0400 Received: from mail-wm0-f67.google.com ([74.125.82.67]:55993 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752730AbeC3DP5 (ORCPT ); Thu, 29 Mar 2018 23:15:57 -0400 Received: by mail-wm0-f67.google.com with SMTP id b127so12909797wmf.5 for ; Thu, 29 Mar 2018 20:15:56 -0700 (PDT) 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=MqNmyguGfYhu4/E+EGeRniZSAKHdV2m4kZR7MbrMg1Y=; b=jBkzzMQBz6gwW/Wu4VOObgFowCII/WUztxZxrgbZMLTOxqJMN1U37UAVFjiy8fNJqX yGKZSNgh2YWsjhHD1/52imESc5pY1P7ik5DSM2dEdQicVWx4HH/UQvtF3Hz3zPRSctZC O8FHr1E4P0Z7jP1+ct6A7QxnrRK2waQVmdsNI= 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=MqNmyguGfYhu4/E+EGeRniZSAKHdV2m4kZR7MbrMg1Y=; b=XkvM5qMxXXh9BEzfdOveL7bOYVxoWG4SbhxsCKXjVOYiavAuQxOp/yU/IQRdM8v01M 4xHzJL7rHeClAolNxN3LKW4SX/7NpGzVID479B0O0tkL14bTiVyIaw7ELPvLBjy/r6yB euojDOVz/i+xRzKVN8028j8C/p4DZGbhU+ZOtmPSNVhiQOnvScHl+HwP9jdZtF7424Qp Ev2Cc5MouN4i9HiShxqI9ZS7RcoMV+aE9PxbAQAY/7u3Xths9XxfJg8DXMPCDa3XEDsU kacZ2fXoECn5nxEwKH92day3OuXme0svSlpTZqfnNHDFLy5ouCQhAEnDGFJ9uixa4oPf ABGg== X-Gm-Message-State: AElRT7E3GeWQVQTP/t07keg+pQoPlOxVxY0Am3uJ5mJynk2rBt0x6zq4 weEAfctWJ9gBDEIst8TEofy+il5rA24= X-Received: by 10.28.202.25 with SMTP id a25mr939986wmg.45.1522379756161; Thu, 29 Mar 2018 20:15:56 -0700 (PDT) Received: from localhost.localdomain (li622-172.members.linode.com. [212.71.249.172]) by smtp.gmail.com with ESMTPSA id z9sm12798903wrz.4.2018.03.29.20.15.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 29 Mar 2018 20:15:55 -0700 (PDT) From: Leo Yan To: Jonathan Corbet , Mathieu Poirier , Greg Kroah-Hartman , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, coresight@lists.linaro.org, Kim Phillips , Mike Leach Cc: Leo Yan Subject: [PATCH v4 2/6] doc: Add documentation for Coresight panic kdump Date: Fri, 30 Mar 2018 11:15:20 +0800 Message-Id: <1522379724-30648-3-git-send-email-leo.yan@linaro.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1522379724-30648-1-git-send-email-leo.yan@linaro.org> References: <1522379724-30648-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 Coresight panic kdump and introduce the implementation of Coresight panic kdump framework; the last section is to explain what's usage. Credits to Mathieu Poirier for many suggestions since the first version patch reviewing. The suggestions include using an array to manage dump related info, this makes code scalable for more CPUs; the Coresight kdump driver and integration kdump flow with other Coresight devices also have many ideas from Mathieu. Suggested-by: Mathieu Poirier Signed-off-by: Leo Yan --- .../trace/coresight/coresight-panic-kdump.txt | 130 +++++++++++++++++++++ MAINTAINERS | 1 + 2 files changed, 131 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..c02e520 --- /dev/null +++ b/Documentation/trace/coresight/coresight-panic-kdump.txt @@ -0,0 +1,130 @@ + Coresight Panic Kdump + ===================== + + Author: Leo Yan + Date: March 29th, 2018 + +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 the 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 being overwritten by each other. Trace Memory Controller (TMC) is +another kind sink designed as a successor to the CoreSight ETB to capture trace +into DRAM. + +After Linux kernel panic has occurred, 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 save trace data into DRAM and rely on +kdump to preserve 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 Coresight dump +functionality when panic happens, it maintains an array for the dump, every array +item is dedicated to one specific CPU by using CPU number as an index. For +'offline' recovery and analysis Coresight tracing data, except should to recovery +tracing data for sinks, we also need to know CPU tracer configurations; for this +purpose, the array item is a structure which combines source and sink device +handlers, the device handler points to Coresight device structure which contains +dump info: dump buffer base address and buffer size. Below diagram is to +present data structures relationship: + + array: coresight_kdump_nodes + +------+------+----------------------+ + | CPU0 | CPU1 | ... | + +------+------+----------------------+ + | + V + coresight_kdump_node coresight_device + +-------------------+ +-------------------+ + | source_csdev | ----------> | kdump_buf | + +-------------------+ / +-------------------+ + | sink_csdev | ----' | kdump_buf_sz | + +-------------------+ +-------------------+ + +Every CPU has its own tracer, we need save tracer registers for tracer ID and +configuration related information as metadata, the metadata is used by tracing +decoder. But the tracer has the different configuration at the different phase, +below diagram explains tracer configurations for different time points: at the +system boot phase, the tracer is disabled so its registers have not been set; +after tracer has been enabled or when panic happens, tracer registers have been +configured, but we need to consider if there has CPU is locked up at panic phase +then this dead CPU has no chance to handle inter-processor interrupt for panic +dump; thus we choose tracer enabling phase to save tracer metadata. Coresight +panic kdump provides API coresight_kdump_source() as helper function for +recording tracer metadata. + + Boot Enabling Panic + + Timeline: ------->|----------->|----------->|-----------> + + Tracer: Disabled Configured Configured + Sink: Disabled Enabled Enabled with tracing data + | | + | `--> Tracing data dump + | + `--> Tracer metadata dump + +After enabling Coresight sink device, function coresight_kdump_sink() is used to +set sink device handler for related CPU; sink device handler points to Coresight +device structure, furthermore we can retrieve its ops structure and panic +callback 'panic_cb' in the ops structure. Coresight panic notifier takes panic CPU +tracing data with high priority to firstly invoke panic CPU sink callback function, +then the notifier iterates dump array and invoke callback functions one by one +for other CPUs. If one sink device is shared among CPUs, the sink panic +callback is invoked for the first traversed CPU node and other sequential CPUs +are skipped. + + +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 7ee1fdc..cc1243b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1333,6 +1333,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 Fri Mar 30 03:15:21 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leo Yan X-Patchwork-Id: 132579 Delivered-To: patch@linaro.org Received: by 10.46.84.29 with SMTP id i29csp2530711ljb; Thu, 29 Mar 2018 20:16:10 -0700 (PDT) X-Google-Smtp-Source: AIpwx49OnRt8gPVVHHYioN4rCuOwncl1/nymDPLy47Oo7TxqUWH67IiOhi00AisExoBos5jTm0+D X-Received: by 2002:a17:902:a701:: with SMTP id w1-v6mr6541897plq.109.1522379770321; Thu, 29 Mar 2018 20:16:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522379770; cv=none; d=google.com; s=arc-20160816; b=ZR8E1Z2hWSoWUgt9fgeVmX4TLBFzcpYBHytgUklaZ2RJxuto6vXzolq12YQ6ygvebB iG407VCu2EdX2Mn0o+tQdXGyRWTBk7YI64cL2reqjVDxQzg42yFsIi4bLU1T7AyTb5/H C0bt+Dszahv1k/0kaYJJuZe2mB0SMHoSdrM/N5aFnDKMN5QQURO8hkmqKP5BosUpcb0b Y3dC6msDwf4Zu4vqIlGFYD9j0u425MycZaJowLWlvYjcBoofwrLi3WVSPAwqi5iYT56E r0wrkFk5aD9R6c4/qDtUzdf+CTznKKzwjvQUkK42hYc+9+43Jlk2oINnybK3IZUfKa6+ hxGg== 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=SC+Y9Dd4/hPslmxENYAISjheGeV9ItZkUbxFlXes27Q=; b=nJADB5h/BWRf7whpH6S+YIOUiYYuu+uBT7WC4kvWDLJxQYx1XwfzPPQnZT6QCJN5xx 4cq+Xu7lFOE08srkIuvNI7RNU0rQ/5ok5kPmukDiTW67gNUms1nIud6Kp2r///XsJW4+ jfo8EvcNmrOwyuAjgjGwNMDpgpQm0nPyLkevJmhgFpAJqhtVlk1O0TN3o1+aClfCPBxf mSzTtAiUobXXNYqwKNwqH4Ru0gdma8ODkF3YcxtZKUsBs4Xr7kfK7N1w8CFoM80GWvJV WkEoy+EkpGd/YBIPmuChwDzu1ttrCig1fWTvUOHWgZEwTP88gYgL9e8Os89Y6/g1m7em WP1Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=Ez0z0TLi; 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 c15si4912599pgu.312.2018.03.29.20.16.10; Thu, 29 Mar 2018 20:16:10 -0700 (PDT) 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=Ez0z0TLi; 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 S1752799AbeC3DQI (ORCPT + 29 others); Thu, 29 Mar 2018 23:16:08 -0400 Received: from mail-wr0-f193.google.com ([209.85.128.193]:34285 "EHLO mail-wr0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752728AbeC3DQC (ORCPT ); Thu, 29 Mar 2018 23:16:02 -0400 Received: by mail-wr0-f193.google.com with SMTP id o8so6994449wra.1 for ; Thu, 29 Mar 2018 20:16:01 -0700 (PDT) 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=SC+Y9Dd4/hPslmxENYAISjheGeV9ItZkUbxFlXes27Q=; b=Ez0z0TLimIW5/ySEPbsKJvIbpYuKaAjYJVSBS04vuM0HFFjc2OmbhT7YYE5XgSckXF P7Soi5whNISe77b45I7HidulQ8eUSlC1TvBdrvpysVoIkqvuw+H9qnEQtsuEthImEMcd NY7iFHyvNQgB1uLvYnCse0RDZbGNkUaRBAcWQ= 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=SC+Y9Dd4/hPslmxENYAISjheGeV9ItZkUbxFlXes27Q=; b=Fsp20c1IUFI1/E9iKLnwSNwyFl61CWhq8eo16QY8dF6dtaDKXkil2Tr8Rbzl61dNi+ eXTpZXyr1pI4o6iIrK5QjSYEpVltGTwxehPL3a30JPy8iStTcO2lW+5kt3SajChPv4AT ntNRPrR/G8snW4Sbz6cM5tsYnjHrdnYCEB+DkalqnkzKGWxBwsJlt92xKpG0WKDpLFoD um4+V8EEawG5cEvst0fNUdvdshE7M1JLfy+MTiXun3psCA3FRJVQYfUgIvXEEwnKXlAd EStk30ggy1/CRD8eMArAbz9u4YMpRALAxG5/+2MqO+iUyx6H9/aMMDb7JjVz6reVyPWs 4pzw== X-Gm-Message-State: AElRT7HlnZDRfVMMVEGgMMapyBGFzB6I2NQI6j2KCqM16tXqemt5ifmQ DMkt1HW2aDHifNGqAEHWkYW6gg== X-Received: by 10.223.154.47 with SMTP id z44mr8040993wrb.239.1522379760693; Thu, 29 Mar 2018 20:16:00 -0700 (PDT) Received: from localhost.localdomain (li622-172.members.linode.com. [212.71.249.172]) by smtp.gmail.com with ESMTPSA id z9sm12798903wrz.4.2018.03.29.20.15.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 29 Mar 2018 20:15:59 -0700 (PDT) From: Leo Yan To: Jonathan Corbet , Mathieu Poirier , Greg Kroah-Hartman , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, coresight@lists.linaro.org, Kim Phillips , Mike Leach Cc: Leo Yan Subject: [PATCH v4 3/6] coresight: Support panic kdump functionality Date: Fri, 30 Mar 2018 11:15:21 +0800 Message-Id: <1522379724-30648-4-git-send-email-leo.yan@linaro.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1522379724-30648-1-git-send-email-leo.yan@linaro.org> References: <1522379724-30648-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 tracing data has much useful info which can be used for analysis. For example, the trace info from ETB RAM can be used to check the CPU execution flows before the 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 the vmcore file. This patch is to add a simple framework to support panic dump functionality; it registers panic notifier, and provide the helper functions coresight_kdump_source()/coresight_kdump_sink() so Coresight source and sink devices can be recorded into Coresight kdump node for kernel panic kdump. When kernel panic happens, the notifier iterates dump array and invoke callback function to dump tracing data. Later the tracing data can be used to reverse execution flow before the kernel panic. Signed-off-by: Leo Yan --- drivers/hwtracing/coresight/Kconfig | 9 + drivers/hwtracing/coresight/Makefile | 1 + .../hwtracing/coresight/coresight-panic-kdump.c | 199 +++++++++++++++++++++ drivers/hwtracing/coresight/coresight-priv.h | 12 ++ include/linux/coresight.h | 4 + 5 files changed, 225 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..3089abf 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 kernel panic happen Coresight device supplied callback function + is to dump trace data to memory. From then on, kdump can be used 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..f4589e9 --- /dev/null +++ b/drivers/hwtracing/coresight/coresight-panic-kdump.c @@ -0,0 +1,199 @@ +// SPDX-License-Identifier: GPL-2.0 +// Copyright (c) 2017~2018 Linaro Limited. +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "coresight-priv.h" + +/** + * struct coresight_kdump_node - Node information for dump + * @source_csdev: Handler for source coresight device + * @sink_csdev: Handler for sink coresight device + */ +struct coresight_kdump_node { + struct coresight_device *source_csdev; + struct coresight_device *sink_csdev; +}; + +static DEFINE_SPINLOCK(coresight_kdump_lock); +static struct coresight_kdump_node *coresight_kdump_nodes; +static struct notifier_block coresight_kdump_nb; + +/** + * coresight_kdump_source - Set source dump info for specific CPU + * @cpu: CPU ID + * @csdev: Source device structure handler + * @data: Pointer for source device metadata buffer + * @data_sz: Size of source device metadata buffer + * + * This function is a helper function which is used to set/clear source device + * handler and metadata when the tracer is enabled; and it can be used to clear + * source device related info when the tracer is disabled. + * + * Returns: 0 on success, negative errno otherwise. + */ +int coresight_kdump_source(int cpu, struct coresight_device *csdev, + char *data, unsigned int data_sz) +{ + struct coresight_kdump_node *node; + unsigned long flags; + + if (!coresight_kdump_nodes) + return -EPROBE_DEFER; + + spin_lock_irqsave(&coresight_kdump_lock, flags); + + node = &coresight_kdump_nodes[cpu]; + node->source_csdev = csdev; + + csdev->kdump_buf = data; + csdev->kdump_buf_sz = data_sz; + + spin_unlock_irqrestore(&coresight_kdump_lock, flags); + return 0; +} + +/** + * coresight_kdump_sink - Set sink device handler for specific CPU + * @cpu: CPU ID + * @csdev: Sink device structure handler + * + * This function is a helper function which is used to set sink device handler + * when the Coresight path has been enabled for specific CPU; and it can be used + * to clear sink device handler when the path is disabled. + * + * Returns: 0 on success, negative errno otherwise. + */ +int coresight_kdump_sink(int cpu, struct coresight_device *csdev) +{ + struct coresight_kdump_node *node; + unsigned long flags; + + if (!coresight_kdump_nodes) + return -EPROBE_DEFER; + + spin_lock_irqsave(&coresight_kdump_lock, flags); + + node = &coresight_kdump_nodes[cpu]; + node->sink_csdev = csdev; + + spin_unlock_irqrestore(&coresight_kdump_lock, flags); + return 0; +} + +/** + * coresight_kdump_sink_cb - Invoke sink callback for specific CPU + * @cpu: CPU ID + * + * This function is to invoke sink device corresponding callback. It needs + * to check two cases: one case is the CPU has not been enabled for Coresight + * path so there totally has no trace data for the CPU, another case is the + * CPU shares the same sink device with other CPUs but the tracing data has + * been dumped by previous CPUs; it skips dump for these two cases. + */ +static void coresight_kdump_sink_cb(int cpu) +{ + struct coresight_kdump_node *node; + struct coresight_device *csdev; + unsigned long flags; + + spin_lock_irqsave(&coresight_kdump_lock, flags); + + node = &coresight_kdump_nodes[cpu]; + csdev = node->sink_csdev; + + /* Path has not been enabled */ + if (!csdev) + goto skip_dump; + + /* Have been dumped by previous CPU */ + if (csdev->kdump_buf) + goto skip_dump; + + /* Invoke panic callback */ + csdev = coresight_kdump_nodes[cpu].sink_csdev; + if (csdev && sink_ops(csdev)->panic_cb) + sink_ops(csdev)->panic_cb(csdev); + +skip_dump: + spin_unlock_irqrestore(&coresight_kdump_lock, flags); +} + +/** + * coresight_kdump_notify - Invoke panic dump callbacks + * @nb: Pointer to notifier block + * @event: Notification reason + * @_unused: Pointer to notification data object, unused + * + * This function is called when panic happens to invoke dump callbacks, it takes + * panic CPU tracing data with high priority to firstly invoke panic CPU sink + * callback function, then the notifier iterates callback functions one by one + * for other CPUs. If one sink device is shared among CPUs, the sink panic + * callback is invoked for the first traversed CPU node and other sequential + * CPUs are skipped. + * + * Returns: 0 on success. + */ +static int coresight_kdump_notify(struct notifier_block *nb, + unsigned long event, void *_unused) +{ + int cpu, first; + + /* Give panic CPU trace data with high priority */ + first = atomic_read(&panic_cpu); + coresight_kdump_sink_cb(first); + + /* Dump rest CPUs trace data */ + for (cpu = 0; cpu < num_possible_cpus(); cpu++) { + if (cpu == first) + continue; + + coresight_kdump_sink_cb(cpu); + } + + return 0; +} + +/** + * coresight_kdump_init - Coresight kdump module initialization + * + * This function allcoates dump array and register panic norifier. + * + * Returns: 0 on success, negative errno otherwise. + */ +static int __init coresight_kdump_init(void) +{ + int ret; + + coresight_kdump_nodes = kmalloc_array(num_possible_cpus(), + sizeof(*coresight_kdump_nodes), + GFP_KERNEL); + if (!coresight_kdump_nodes) { + pr_err("%s: kmalloc failed\n", __func__); + return -ENOMEM; + } + + memset(coresight_kdump_nodes, 0, + num_possible_cpus() * sizeof(*coresight_kdump_nodes)); + + coresight_kdump_nb.notifier_call = coresight_kdump_notify; + ret = atomic_notifier_chain_register(&panic_notifier_list, + &coresight_kdump_nb); + if (ret) { + pr_err("%s: unable to register notifier: %d\n", + __func__, ret); + kfree(coresight_kdump_nodes); + return ret; + } + + return 0; +} +postcore_initcall(coresight_kdump_init); diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h index f1d0e21d..76d27d6 100644 --- a/drivers/hwtracing/coresight/coresight-priv.h +++ b/drivers/hwtracing/coresight/coresight-priv.h @@ -151,4 +151,16 @@ 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_source(int cpu, struct coresight_device *csdev, + char *data, unsigned int data_sz); +extern int coresight_kdump_sink(int cpu, struct coresight_device *csdev); +#else +static inline int coresight_kdump_source(int cpu, + struct coresight_device *csdev, + char *data, unsigned int data_sz) { return 0; } +static inline void coresight_kdump_sink(int cpu, + struct coresight_device *csdev) { return 0; } +#endif + #endif diff --git a/include/linux/coresight.h b/include/linux/coresight.h index d950dad..89aad8d 100644 --- a/include/linux/coresight.h +++ b/include/linux/coresight.h @@ -171,6 +171,8 @@ 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 */ + char *kdump_buf; + unsigned int kdump_buf_sz; }; #define to_coresight_device(d) container_of(d, struct coresight_device, dev) @@ -189,6 +191,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 +208,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); }; /** From patchwork Fri Mar 30 03:15:22 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leo Yan X-Patchwork-Id: 132582 Delivered-To: patch@linaro.org Received: by 10.46.84.29 with SMTP id i29csp2531269ljb; Thu, 29 Mar 2018 20:16:58 -0700 (PDT) X-Google-Smtp-Source: AIpwx49VjenO7aFRBeVR1BsUvyriwvUhv3QnVTGgmS4yN4ZgdbmmwEBUfeWfU3oIK6N2KILsuO2h X-Received: by 10.99.147.82 with SMTP id w18mr7169356pgm.181.1522379818698; Thu, 29 Mar 2018 20:16:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522379818; cv=none; d=google.com; s=arc-20160816; b=LxfM4aGRAYSQWmvuL2WhgHt+MA+n/pVkDuAPSbbJN+Noo+WMU8uRto90gMeZdls8TY vEswkSTxrMLJiYiEycydm5/LTydJfl7QObv6deroTVsoLvu0DJDjqVsvjcTew+qHpeeY O9WoLrwfWUJXEbmQWXaJaZzaoYh+jf4BPWE7vaGa2MUnYO9/vKrxRfC2dJw0VVzGXVjL 4cR2Sajc1So4o6u8daAWdIwZEWl+jYZmCl4QQrBE9ka5nEhgfX2XM2eHCE6ipBzBTDi0 WjG67RCBkKzUTOqeNuCBQimTTxHPM3EhuBRGMwTIguNsgJdmnu0OYo091yCflqx39Sxi ce3w== 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=HpmWK/7Q87q15GSW6+wUQSscqm4fAYVRmYYCeuwbnNw=; b=pGWvafU7KIgO11I6OfGTZtf9KOqIS1Szvj8bIhIGNYOVEndQyOmP+SABQftSpaS2r+ PbvQvphInaGskAZPKI8ovYMsOlZf2yQfPZfnqoinkSOrpLP320p9OFxT4K93mApEKC3s m1salT5LydAz0QYdjazYyC6odu0pP2fC2gwOyKKa2kqZSOe1TWAWoDlquj3ISNf7nsHH UHsnLZXiujekleMmqcojYUU5uk7k5aKLPjh4rUiaOu2pXPkRXIptqPw1aAHSch5pjPaE J9h40+Cidf07MKv2pXEGvie2qqC4RSW06ki+FY2r/767CsKqiK+LnhNnS8jrAB6jzkGZ Plrg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=XMsb5V8m; 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 o5-v6si7512908plh.432.2018.03.29.20.16.58; Thu, 29 Mar 2018 20:16:58 -0700 (PDT) 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=XMsb5V8m; 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 S1752918AbeC3DQ4 (ORCPT + 29 others); Thu, 29 Mar 2018 23:16:56 -0400 Received: from mail-wr0-f195.google.com ([209.85.128.195]:38934 "EHLO mail-wr0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752770AbeC3DQG (ORCPT ); Thu, 29 Mar 2018 23:16:06 -0400 Received: by mail-wr0-f195.google.com with SMTP id c24so6978741wrc.6 for ; Thu, 29 Mar 2018 20:16:05 -0700 (PDT) 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=HpmWK/7Q87q15GSW6+wUQSscqm4fAYVRmYYCeuwbnNw=; b=XMsb5V8mWGdb8zdXU8hFQKiaUsQtP3E05ZpNZH86+hGmcnr5r1ObPUgPmzIg+cD8jy YCKGCkdIQtxL3eYFEmBv3+ZyxTO+k6AGMFXEUylpDLO4kV/vH80sEM16IwrdKg5lVR0l ZVbRdP47268iRTcILxhJcQ3W7ir9yoJyCsegg= 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=HpmWK/7Q87q15GSW6+wUQSscqm4fAYVRmYYCeuwbnNw=; b=R7fgQ391kWv6k2SqiY4Lstcqn+HvJL1AFD7VtyA2kNwig+ADbg5Tu6iRU3xvdXJfnO uudpoKtWADsNgnbuZ3bE4JDfWM1Z/HUIaC0esnfjnI59ZjKN5Zkvh1LiYUSzkgtUoJMX jpsjpflNyDcEqIHCxLnaJ79s7JfH9WQmSWS8rAOvdQcBeYy7rq7u1n/WGV18MBuDunoN tQp7qC5L+RSQyqp9rCkTZE4z+NQH6VDxZ/PaK7P1Tx+9le9XmOWB+98fAgkgbMgy3hCo G2LRFUTeGO/9Mevcrb3KuApVZQflyh1FU9bEc2jR7FTQh2VpSnzsefIV+Wt5tTongLi3 /bcg== X-Gm-Message-State: AElRT7HdDynt754GnDZgkxpqEzDIRPuGh5Pyp8u093RZHMsUNAPMB9vn mGy/yRocKd/a7etQwhBgavwSRQ== X-Received: by 10.223.176.253 with SMTP id j58mr8270564wra.269.1522379765011; Thu, 29 Mar 2018 20:16:05 -0700 (PDT) Received: from localhost.localdomain (li622-172.members.linode.com. [212.71.249.172]) by smtp.gmail.com with ESMTPSA id z9sm12798903wrz.4.2018.03.29.20.16.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 29 Mar 2018 20:16:04 -0700 (PDT) From: Leo Yan To: Jonathan Corbet , Mathieu Poirier , Greg Kroah-Hartman , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, coresight@lists.linaro.org, Kim Phillips , Mike Leach Cc: Leo Yan Subject: [PATCH v4 4/6] coresight: tmc: Hook callback for panic kdump Date: Fri, 30 Mar 2018 11:15:22 +0800 Message-Id: <1522379724-30648-5-git-send-email-leo.yan@linaro.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1522379724-30648-1-git-send-email-leo.yan@linaro.org> References: <1522379724-30648-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 Coresight panic kdump functionality has been ready, this patch is to hook panic callback function for ETB/ETF driver. The driver data structure has allocated a buffer when the session started, so simply save tracing data into this buffer when panic happens and update buffer related info for kdump. Signed-off-by: Leo Yan --- drivers/hwtracing/coresight/coresight-tmc-etf.c | 30 +++++++++++++++++++++++++ 1 file changed, 30 insertions(+) -- 2.7.4 diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c b/drivers/hwtracing/coresight/coresight-tmc-etf.c index e2513b7..d20d546 100644 --- a/drivers/hwtracing/coresight/coresight-tmc-etf.c +++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c @@ -504,6 +504,35 @@ 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 */ + csdev->kdump_buf = drvdata->buf; + csdev->kdump_buf_sz = 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 +541,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 Fri Mar 30 03:15:23 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leo Yan X-Patchwork-Id: 132580 Delivered-To: patch@linaro.org Received: by 10.46.84.29 with SMTP id i29csp2530798ljb; Thu, 29 Mar 2018 20:16:16 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/eeH3/x8WOVPOvI7ajAzkyOORN1Pt9ZHZMAre+uA9KwAGRkFQb1INFPilJqTDAbfY+J24n X-Received: by 2002:a17:902:1006:: with SMTP id b6-v6mr11175951pla.252.1522379776838; Thu, 29 Mar 2018 20:16:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522379776; cv=none; d=google.com; s=arc-20160816; b=fpeWxA76Letp5eJFz/qm3hcvdGyzEakPUsVh/GGSF9i5oejRy96rdddM2Eeb7VjnNH 69skgeL2iJ6rfnfX0KvHVz1pWe9D1tglq5konYgw64QVTb0HJ5gTrNK6CVA1F2BMIejY A8GHCP5St+f1lJHC0/SUGPsAX2Zfz06L6JQU6UvPQ8zHGYLGLZy5cL3YWtijWmO8s8GN AO6zj1eWNdcvYblCFjZVbvKPVObV9NdQMCXdSl+CEPmkNnWwTTKhMuQwMWZB0dRVesOn 7o9V4r50zUpgRuyYqoQpmV+ND4EyvaSSZyjdcaqoD4p/T1bVKznRM+Rw8rYz35WdyWv9 HepA== 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=Q2kDM5YY0TwXhvJ2W20sii7DcFnE2eb+0roImoIBLhE=; b=YzxVgKL/uF7zoZasRFhhVpUTzQIy2E5ghciPMQDlmINp42+o+oNVhXs3nGCmn+zPlT X4l/zsdTMRi/F6B/RhP2V17gB1r+kSYKuLE/+dWHR56Y7ZujZ5R3TsjTrP/vMdqc0/81 viPK5TtbeHrpSn8BCWTFGsU5vPAh4ZeqHanUySO/iwl5etF02YHdP11VhHJ0o3syyO4a w5Q5ph4CDPKirprSNelSqyGfZ3a8y3XuhbtyQ/a5aUSC5lIPqQep9c6UUXJ7Sek7gSJn ZF2rhHTYSNgHEdBYVD/ABTu01w1XHHUBoumoe6aajpGjO3mzYxE/C3pC94+pUJQXyQ9/ vzzQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=GMNqn4QN; 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 c15si4912599pgu.312.2018.03.29.20.16.16; Thu, 29 Mar 2018 20:16:16 -0700 (PDT) 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=GMNqn4QN; 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 S1752838AbeC3DQN (ORCPT + 29 others); Thu, 29 Mar 2018 23:16:13 -0400 Received: from mail-wr0-f193.google.com ([209.85.128.193]:43106 "EHLO mail-wr0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752800AbeC3DQK (ORCPT ); Thu, 29 Mar 2018 23:16:10 -0400 Received: by mail-wr0-f193.google.com with SMTP id p53so6965400wrc.10 for ; Thu, 29 Mar 2018 20:16:10 -0700 (PDT) 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=Q2kDM5YY0TwXhvJ2W20sii7DcFnE2eb+0roImoIBLhE=; b=GMNqn4QNPZXZgme8ePFR/DJMWeGcXC9pfBLGKxc8Mz3yfap/sCbEP1P+fm/TwPFf98 PSE/aUa17YScshfBnO9QWfqbmV1jsMnGuT62Tl7kKpNFrMfZgRiMAnudRwju5ZGj222D 1xpXEnyk2ICSOukguQsmIDSdGrzsQbIhGEZKo= 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=Q2kDM5YY0TwXhvJ2W20sii7DcFnE2eb+0roImoIBLhE=; b=EcDa1DYLhmgL6EHhbs+JgbV9X1HL3fPDeu1jPscFuAcx9/elIVUAZ4YngBLM3Kj/jJ xZdcWwtWq4kCz792xZlrVkkPfNYzDQG4Pd8a+0JgLNbwywuPPnKhllRBKbDc+5Xhu0L1 lS+2qeWLc0W5TYATDhGxBe2DbtVj9ZqVu7v4qPcMSJ0cBN/OWL0a/fLshFz/nFDyF8id gybs2VwZXOZ/sbB682wMqKlZSOqtB0f+PtrkMajQhc3wnu7d6D0lab+tiJHbyWCrrNDj YYyRmouUQzvuKxVAvriGUEpvGrhk0Jk+QoXDRCB5aoE6FL1oe4oIYNpVuebt5ZFqkyJ2 4wtw== X-Gm-Message-State: AElRT7GiXdKzMDKzivL6/eq/QQJMvIjcyAlHUWeTAurA2qPNP9VIv0um OgX23xURI6P6cv+1OTIumhbDsQ== X-Received: by 10.223.227.73 with SMTP id n9mr8011978wrj.134.1522379769345; Thu, 29 Mar 2018 20:16:09 -0700 (PDT) Received: from localhost.localdomain (li622-172.members.linode.com. [212.71.249.172]) by smtp.gmail.com with ESMTPSA id z9sm12798903wrz.4.2018.03.29.20.16.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 29 Mar 2018 20:16:08 -0700 (PDT) From: Leo Yan To: Jonathan Corbet , Mathieu Poirier , Greg Kroah-Hartman , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, coresight@lists.linaro.org, Kim Phillips , Mike Leach Cc: Leo Yan Subject: [PATCH v4 5/6] coresight: Set and clear sink device handler for kdump node Date: Fri, 30 Mar 2018 11:15:23 +0800 Message-Id: <1522379724-30648-6-git-send-email-leo.yan@linaro.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1522379724-30648-1-git-send-email-leo.yan@linaro.org> References: <1522379724-30648-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 Coresight path is enabled for specific CPU, the sink device handler need to be set to kdump node; on the other hand we also need to clear sink device handler when path is disabled. This patch sets sink devices handler for kdump node for two separate Coresight enabling modes: CS_MODE_SYSFS and CS_MODE_PERF; and clear the handler when Coresight is disabled. Signed-off-by: Leo Yan --- drivers/hwtracing/coresight/coresight-etm-perf.c | 5 +++++ drivers/hwtracing/coresight/coresight.c | 16 ++++++++++++++-- 2 files changed, 19 insertions(+), 2 deletions(-) -- 2.7.4 diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c index 8a0ad77..f8b159c 100644 --- a/drivers/hwtracing/coresight/coresight-etm-perf.c +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c @@ -139,6 +139,8 @@ static void free_event_data(struct work_struct *work) for_each_cpu(cpu, mask) { if (!(IS_ERR_OR_NULL(event_data->path[cpu]))) coresight_release_path(event_data->path[cpu]); + + coresight_kdump_sink(cpu, NULL); } kfree(event_data->path); @@ -238,6 +240,9 @@ 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; + + if (coresight_kdump_sink(cpu, sink)) + goto err; } if (!sink_ops(sink)->alloc_buffer) diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c index 389c4ba..483a1f7 100644 --- a/drivers/hwtracing/coresight/coresight.c +++ b/drivers/hwtracing/coresight/coresight.c @@ -272,6 +272,7 @@ static int coresight_enable_source(struct coresight_device *csdev, u32 mode) static bool coresight_disable_source(struct coresight_device *csdev) { if (atomic_dec_return(csdev->refcnt) == 0) { + if (source_ops(csdev)->disable) source_ops(csdev)->disable(csdev, NULL); csdev->enable = false; @@ -612,6 +613,13 @@ int coresight_enable(struct coresight_device *csdev) if (ret) goto err_source; + cpu = source_ops(csdev)->cpu_id(csdev); + + /* Set sink device handler into kdump node */ + ret = coresight_kdump_sink(cpu, sink); + if (ret) + goto err_kdump; + switch (subtype) { case CORESIGHT_DEV_SUBTYPE_SOURCE_PROC: /* @@ -621,7 +629,6 @@ int coresight_enable(struct coresight_device *csdev) * be a single session per tracer (when working from sysFS) * a per-cpu variable will do just fine. */ - cpu = source_ops(csdev)->cpu_id(csdev); per_cpu(tracer_path, cpu) = path; break; case CORESIGHT_DEV_SUBTYPE_SOURCE_SOFTWARE: @@ -636,6 +643,9 @@ int coresight_enable(struct coresight_device *csdev) mutex_unlock(&coresight_mutex); return ret; +err_kdump: + coresight_disable_source(csdev); + err_source: coresight_disable_path(path); @@ -659,9 +669,10 @@ void coresight_disable(struct coresight_device *csdev) if (!csdev->enable || !coresight_disable_source(csdev)) goto out; + cpu = source_ops(csdev)->cpu_id(csdev); + switch (csdev->subtype.source_subtype) { case CORESIGHT_DEV_SUBTYPE_SOURCE_PROC: - cpu = source_ops(csdev)->cpu_id(csdev); path = per_cpu(tracer_path, cpu); per_cpu(tracer_path, cpu) = NULL; break; @@ -674,6 +685,7 @@ void coresight_disable(struct coresight_device *csdev) break; } + coresight_kdump_sink(cpu, NULL); coresight_disable_path(path); coresight_release_path(path); From patchwork Fri Mar 30 03:15:24 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leo Yan X-Patchwork-Id: 132581 Delivered-To: patch@linaro.org Received: by 10.46.84.29 with SMTP id i29csp2530831ljb; Thu, 29 Mar 2018 20:16:20 -0700 (PDT) X-Google-Smtp-Source: AIpwx49171FWWYchC3ycSrAT6yXJlRk2ntm7exQT16lvNKGoXQ0O/EJ/UAknfWZyEDt2pyulDz9P X-Received: by 10.98.87.7 with SMTP id l7mr8451342pfb.148.1522379780265; Thu, 29 Mar 2018 20:16:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522379780; cv=none; d=google.com; s=arc-20160816; b=wG1neu7KpUKZFYaHf9n08jWvKpHbsczdv75yx9H2/vMlGnNDsusiSkZ7IJJVJ52PMq R1E3vt3gRHM3Cq5tJ3SyQ7t4VFkoInFIIctYrGVUjaynJivuYC8LIjOQqftZ18oMXNZ5 UKXqX5lpLO71qGKR6w+4DfZ63tP/6rkzHDhEOHmQyU28369/7MoLHGYRHM+Mr5BVJrF2 2rEWUflnWBWbDl+2kwkUgktZPeTDVhy+gjf+9/yzGxCOj+/fxpWL3yOw5wvHAksFB+r6 OXbFgyV1jjpbdbU1Ze77ysUIZ5tyJD7QLs4ozX1CpkNEEk9bJT+zG50Qr4y2R5X0lJ+8 JlwQ== 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=gsayClFC98iYx6/DqOyvc4Nh2Po2oTAyjfQNyaF63bo=; b=mSZioiLHxPG1KuobkI8+pdUxZh9Id/IiN5dc5s8myeKIsIkiSsOoALbHjulM7VC/99 1fk5VU/+JLjjfEnPxu/tYoVRYPPzTXJgz2GSirFUXHBSHczklmDPWMoGbEf7Lo9kjzZV PcG1L+4m+IjHGCZcIN4TX7SoqrktZuMgdgtk/TPDWPhXjQwLLld2XLjnK70isOc6P+t/ UnNyHeFeWzwLF4CmpIdSbjiPo6p62fBCt50fBNLudGpojn46i+DW7RLo0Jd4FJcdn46F 66W9h4M49aFhXnC/TtjhRVhoGNQ2PSCcwHJ/WH/T1E8NSMUVmEPUSuFz6k8nIlBdyeRI cPuQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=jVhtZPFl; 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 c15si4912599pgu.312.2018.03.29.20.16.19; Thu, 29 Mar 2018 20:16:20 -0700 (PDT) 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=jVhtZPFl; 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 S1752864AbeC3DQS (ORCPT + 29 others); Thu, 29 Mar 2018 23:16:18 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:51780 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752840AbeC3DQP (ORCPT ); Thu, 29 Mar 2018 23:16:15 -0400 Received: by mail-wm0-f68.google.com with SMTP id v21so13788930wmc.1 for ; Thu, 29 Mar 2018 20:16:14 -0700 (PDT) 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=gsayClFC98iYx6/DqOyvc4Nh2Po2oTAyjfQNyaF63bo=; b=jVhtZPFl0kII/TF4P7WL6AmIIxkdny77kI8hs5UvnFEoEv8j0OrCQrRhTqWmS1kenX ug6VnsEmhNmQ/JDkFE2jWN1pvEYYGyF8qewsZyRpqbwVGT97KDDw+7oGbQK1VoZCdkem mwuTvS+YdUG8foCTCujbnSuYzJ8NkQUCtnIC0= 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=gsayClFC98iYx6/DqOyvc4Nh2Po2oTAyjfQNyaF63bo=; b=O8/ggYqAlfXU8y+Ib/j11R55iJODrpMlMwzS1EqFBEPszzARQu+Newm+BJmEZMJDo4 ei1H6vQdaMEs0tPA0qr3/Jc53RAMG3C/TCofuUMYzKY5YhTuPzur/0i4BF19plXdfUC+ O0jUw6IC7e3daVcp1bgaVyy5HZOu6W/Z258suf/lOjw4R3WyhujnznIx7hc7obX49HKj IEnJQqU3e5k4622ElhytiidFCq9eYBdq52zLzg/McO6SdZICN7edcN0UlKSoeLxcCOy1 RvtXohS488y0RNYuIDRquXJSAapLrCr/+f7O6rOFLv+yzkBLBlS9/52ueSq9/VN3tcI2 Hgug== X-Gm-Message-State: AElRT7FGtWUbGRYDPYski+qzxdu4CPugIvy5kqbQCglwexzamxl0cguT 2xmoQosrS1kQmS41lNOqUDX+cK6fbdM= X-Received: by 10.28.1.197 with SMTP id 188mr920701wmb.49.1522379773967; Thu, 29 Mar 2018 20:16:13 -0700 (PDT) Received: from localhost.localdomain (li622-172.members.linode.com. [212.71.249.172]) by smtp.gmail.com with ESMTPSA id z9sm12798903wrz.4.2018.03.29.20.16.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 29 Mar 2018 20:16:13 -0700 (PDT) From: Leo Yan To: Jonathan Corbet , Mathieu Poirier , Greg Kroah-Hartman , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, coresight@lists.linaro.org, Kim Phillips , Mike Leach Cc: Leo Yan Subject: [PATCH v4 6/6] coresight: etm4x: Support panic kdump Date: Fri, 30 Mar 2018 11:15:24 +0800 Message-Id: <1522379724-30648-7-git-send-email-leo.yan@linaro.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1522379724-30648-1-git-send-email-leo.yan@linaro.org> References: <1522379724-30648-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; the metadata format should be compatible with 'perf' tool and finally is used by tracing data decoder. ETMv4 works as tracer per CPU, we cannot wait for gathering ETM info after CPU panic has happened in case there have CPU is locked up and can't response inter-processor interrupt for execution dump operations; so it's more reliable to gather tracer metadata when all of the CPUs are alive. This patch saves ETMv4 metadata but with the different method for different registers. Since values in TRCIDR{0, 1, 2, 8} and TRCAUTHSTATUS are read-only and won't change afterward, thus those registers values are filled into metadata structure when tracers are instantiated. The configuration and control registers TRCCONFIGR and TRCTRACEIDR are dynamically configured, their values are recorded during tracer enabling phase. To avoid unnecessary overload introduced by set/clear operations for updating kdump node, we only set ETMv4 metadata info for the corresponding kdump node at initialization and won't be cleared anymore. Suggested-by: Mathieu Poirier Signed-off-by: Leo Yan --- drivers/hwtracing/coresight/coresight-etm4x.c | 27 +++++++++++++++++++++++++++ drivers/hwtracing/coresight/coresight-etm4x.h | 15 +++++++++++++++ 2 files changed, 42 insertions(+) -- 2.7.4 diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c index cf364a5..88b1e19 100644 --- a/drivers/hwtracing/coresight/coresight-etm4x.c +++ b/drivers/hwtracing/coresight/coresight-etm4x.c @@ -288,6 +288,8 @@ static int etm4_enable(struct coresight_device *csdev, int ret; u32 val; struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent); + struct etmv4_config *config = &drvdata->config; + struct etmv4_metadata *metadata = &drvdata->metadata; val = local_cmpxchg(&drvdata->mode, CS_MODE_DISABLED, mode); @@ -306,6 +308,10 @@ static int etm4_enable(struct coresight_device *csdev, ret = -EINVAL; } + /* Update tracer meta data after tracer configuration */ + metadata->trcconfigr = config->cfg; + metadata->trctraceidr = drvdata->trcid; + /* The tracer didn't start */ if (ret) local_set(&drvdata->mode, CS_MODE_DISABLED); @@ -438,6 +444,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 +597,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); } @@ -957,6 +974,7 @@ static int etm4_probe(struct amba_device *adev, const struct amba_id *id) struct device *dev = &adev->dev; struct coresight_platform_data *pdata = NULL; struct etmv4_drvdata *drvdata; + struct etmv4_metadata *metadata; struct resource *res = &adev->res; struct coresight_desc desc = { 0 }; struct device_node *np = adev->dev.of_node; @@ -1027,6 +1045,15 @@ static int etm4_probe(struct amba_device *adev, const struct amba_id *id) goto err_arch_supported; } + /* Set source device handler and metadata into kdump node */ + metadata = &drvdata->metadata; + ret = coresight_kdump_source(drvdata->cpu, drvdata->csdev, + (char *)metadata, sizeof(*metadata)); + if (ret) { + coresight_unregister(drvdata->csdev); + goto err_arch_supported; + } + ret = etm_perf_symlink(drvdata->csdev, true); if (ret) { coresight_unregister(drvdata->csdev); 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 */