Lines Matching +full:power +full:- +full:on
9 ------------
11 Coresight CPU debug module is defined in ARMv8-a architecture reference manual
13 debug module and it is mainly used for two modes: self-hosted debug and
15 debugger connects with SoC from JTAG port; on the other hand the program can
16 explore debugging method which rely on self-hosted debug mode, this document
17 is to focus on this part.
19 The debug module provides sample-based profiling extension, which can be used
21 every CPU has one dedicated debug module to be connected. Based on self-hosted
29 --------------
31 - During driver registration, it uses EDDEVID and EDDEVID1 - two device ID
32 registers to decide if sample-based profiling is implemented or not. On some
36 - At the time this documentation was written, the debug driver mainly relies on
43 - The driver supports a CPU running in either AArch64 or AArch32 mode. The
49 - ARMv8-a (ARM DDI 0487A.k) and ARMv7-a (ARM DDI 0406C.b) have different
52 If PCSROffset=0b0000, on ARMv8-a the feature of EDPCSR is not implemented;
53 but ARMv7-a defines "PCSR samples are offset by a value that depends on the
54 instruction set state". For ARMv7-a, the driver checks furthermore if CPU
56 detailed description for offset is in ARMv7-a ARM (ARM DDI 0406C.b) chapter
59 If PCSROffset=0b0010, ARMv8-a defines "EDPCSR implemented, and samples have
61 state". So on ARMv8 if EDDEVID1.PCSROffset is 0b0010 and the CPU operates
66 Clock and power domain
67 ----------------------
69 Before accessing debug registers, we should ensure the clock and power domain
70 have been enabled properly. In ARMv8-a ARM (ARM DDI 0487A.k) chapter 'H9.1
75 +---------------+
78 +----------+--+ |
79 dbg_clock -->| |**| |<-- cpu_clock
81 dbg_power_domain -->| |**| |<-- cpu_power_domain
82 +----------+--+ |
85 +---------------+
87 For debug domain, the user uses DT binding "clocks" and "power-domains" to
88 specify the corresponding clock source and power supply for the debug logic.
90 debug power domain.
92 For CPU domain, the different SoC designs have different power management
96 - On systems with a sane power controller which can behave correctly with
97 respect to CPU power domain, the CPU power domain can be controlled by
99 to power up the CPU, and then writes bit EDPRCR.CORENPDRQ for emulation
100 of CPU power down. As result, this can ensure the CPU power domain is
101 powered on properly during the period when access debug related registers;
103 - Some designs will power down an entire cluster if all CPUs on the cluster
104 are powered down - including the parts of the debug registers that should
105 remain powered in the debug power domain. The bits in EDPRCR are not
107 power down in the way that the CoreSight / Debug designers anticipated.
112 is a recipe for disaster; so we need preventing CPU low power states at boot
118 --------------------
120 See Documentation/devicetree/bindings/arm/arm,coresight-cpu-debug.yaml for
125 ---------------------
147 As explained in chapter "Clock and power domain", if you are working on one
148 platform which has idle states to power off debug logic and the power
160 interface (see Documentation/power/pm_qos_interface.rst for more
169 # exec 3<>-
174 Documentation/admin-guide/pm/cpuidle.rst)::
179 -------------
184 coresight-cpu-debug 850000.debug: CPU[0]:
185 coresight-cpu-debug 850000.debug: EDPRSR: 00000001 (Power:On DLK:Unlock)
186 coresight-cpu-debug 850000.debug: EDPCSR: handle_IPI+0x174/0x1d8
187 coresight-cpu-debug 850000.debug: EDCIDSR: 00000000
188 …coresight-cpu-debug 850000.debug: EDVIDSR: 90000000 (State:Non-secure Mode:EL1/0 Width:64bits VMI…
189 coresight-cpu-debug 852000.debug: CPU[1]:
190 coresight-cpu-debug 852000.debug: EDPRSR: 00000001 (Power:On DLK:Unlock)
191 coresight-cpu-debug 852000.debug: EDPCSR: debug_notifier_call+0x23c/0x358
192 coresight-cpu-debug 852000.debug: EDCIDSR: 00000000
193 …coresight-cpu-debug 852000.debug: EDVIDSR: 90000000 (State:Non-secure Mode:EL1/0 Width:64bits VMI…