]>
Commit | Line | Data |
---|---|---|
d006af40 AF |
1 | From 76c1d8cdfa0967b04ca8168a77bb101d4ea71150 Mon Sep 17 00:00:00 2001 |
2 | From: Santosh Shilimkar <santosh.shilimkar@ti.com> | |
3 | Date: Mon, 18 Mar 2013 06:51:30 +0000 | |
4 | Subject: [PATCH 6/6] ARM: hw_breakpoint: Enable debug powerdown only if | |
5 | system supports 'has_ossr' | |
6 | ||
7 | On Friday 15 March 2013 10:30 AM, Will Deacon wrote: | |
8 | > On Thu, Mar 14, 2013 at 01:08:00PM +0530, Santosh Shilimkar wrote: | |
9 | >> Will, | |
10 | > | |
11 | > Hi guys, | |
12 | > | |
13 | > I'm out of the office at the moment and have really terrible connectivity, | |
14 | > so I can't do too much until next week. However, I don't think adding the | |
15 | > has_ossr check is the right fix for this problem. | |
16 | > | |
17 | >> On Wednesday 13 March 2013 05:59 PM, Lokesh Vutla wrote: | |
18 | >>> Hi Dietmar, | |
19 | >>> On Wednesday 13 March 2013 05:35 PM, Dietmar Eggemann wrote: | |
20 | >>>> On 13/03/13 06:52, Lokesh Vutla wrote: | |
21 | >>>>> Commit {9a6eb31 ARM: hw_breakpoint: Debug powerdown support for | |
22 | >>>>> self-hosted | |
23 | >>>>> debug} introduces debug powerdown support for self-hosted debug. | |
24 | >>>>> While merging the patch 'has_ossr' check was removed which | |
25 | >>>>> was needed for hardwares which doesn't support self-hosted debug. | |
26 | >>>>> Pandaboard (A9) is one such hardware and Dietmar's orginial | |
27 | >>>>> patch did mention this issue. | |
28 | >>>>> Without that check on Panda with CPUIDLE enabled, a flood of | |
29 | >>>>> below messages thrown. | |
30 | >>>>> | |
31 | >>>>> [ 3.597930] hw-breakpoint: CPU 0 failed to disable vector catch | |
32 | >>>>> [ 3.597991] hw-breakpoint: CPU 1 failed to disable vector catch | |
33 | > | |
34 | > Ok, so this means that we've taken an undefined instruction exception while | |
35 | > trying to reset the debug registers on the PM_EXIT path. Now, the code there | |
36 | > deals with CPUs that don't have the save/restore registers just fine, so | |
37 | > that shouldn't have anything to do with this problem, particularly if the | |
38 | > bit that is tripping us up is related to clearing vector catch. | |
39 | > | |
40 | Agree. | |
41 | ||
42 | > Furthermore, I was under the impression that hw_breakpoint did actually | |
43 | > work on panda, which implies that a cold boot *does* manage to reset the | |
44 | > registers (can you please confirm this by looking in your dmesg during | |
45 | > boot?). In that case, it seems as though a PM cycle is powering down a | |
46 | > bunch of debug logic that was powered up during boot, and then we trip over | |
47 | > because we can't access the register bank. | |
48 | > | |
49 | Actually it seems to be without PM. Thanks to analysis from Lokesh, the issue | |
50 | can be seen even with just suspend or cpu hotplug. So cold boot as such is | |
51 | fine. | |
52 | ||
53 | > The proper solution to this problem requires us to establish exactly what is | |
54 | > turning off the debug registers, and then having an OMAP PM notifier to | |
55 | > enable it again. Assuming this has always been the case, I expect hardware | |
56 | > debug across PM fails silently with older kernels. | |
57 | > | |
58 | This has been always the case it seems with CPU power cycle. | |
59 | After the CPU is power cycled, 'DBGAUTHSTATUS' reads '0xaa' rather | |
60 | than '0xaf' which means 'DBGEN = 0' and hence code fails to enable | |
61 | monitor mode. This happens on both secure and GP devices and it can not | |
62 | be patched since the secure code is ROM'ed. We didn't notice so far | |
63 | because hw_breakpoint support was not default enabled on OMAP till the | |
64 | multi-platform build. | |
65 | ||
66 | >> I was also wondering whether we should just warn once rather | |
67 | >> than continuous warnings in the notifier. Patch is end of the | |
68 | >> email. | |
69 | > | |
70 | > Could do, but I'd like to see a fix for the real issue before we simply hide | |
71 | > the warnings :) | |
72 | > | |
73 | Agree here too. As evident above, the feature won't work on OMAP4 | |
74 | devices with PM and hence some solution is needed. | |
75 | ||
76 | What you think of below ? | |
77 | ||
78 | >From d74b4264f6a5967b0f7ada96aad77ab0ac30dbed Mon Sep 17 00:00:00 2001 | |
79 | From: Santosh Shilimkar <santosh.shilimkar@ti.com> | |
80 | Date: Mon, 18 Mar 2013 11:59:04 +0530 | |
81 | Subject: [PATCH] ARM: hw_breakpoints: Check for CPU debug availability before | |
82 | enabling it | |
83 | ||
84 | CPU debug features like hardware break, watchpoints can be used only when | |
85 | the debug mode is enabled and available for non-secure mode. | |
86 | ||
87 | Hence check 'DBGAUTHSTATUS.DBGEN' before proceeding to enable the | |
88 | features. | |
89 | ||
90 | Thanks to Will for pointers and Lokesh for the analysis of the issue on | |
91 | OMAP4 where after a CPU power cycle, debug mode gets disabled. | |
92 | ||
93 | Cc: Will Deacon <Will.Deacon@arm.com> | |
94 | ||
95 | Tested-by: Lokesh Vutla <lokeshvutla@ti.com> | |
96 | Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> | |
97 | --- | |
98 | arch/arm/kernel/hw_breakpoint.c | 8 ++++++++ | |
99 | 1 file changed, 8 insertions(+) | |
100 | ||
101 | diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c | |
102 | index 96093b7..683a7cf 100644 | |
103 | --- a/arch/arm/kernel/hw_breakpoint.c | |
104 | +++ b/arch/arm/kernel/hw_breakpoint.c | |
105 | @@ -930,6 +930,14 @@ static void reset_ctrl_regs(void *unused) | |
106 | int i, raw_num_brps, err = 0, cpu = smp_processor_id(); | |
107 | u32 val; | |
108 | ||
109 | + /* Check if we have access to CPU debug features */ | |
110 | + ARM_DBG_READ(c7, c14, 6, val); | |
111 | + if ((val & 0x1) == 0) { | |
112 | + pr_warn_once("CPU %d debug is unavailable\n", cpu); | |
113 | + cpumask_or(&debug_err_mask, &debug_err_mask, cpumask_of(cpu)); | |
114 | + return; | |
115 | + } | |
116 | + | |
117 | /* | |
118 | * v7 debug contains save and restore registers so that debug state | |
119 | * can be maintained across low-power modes without leaving the debug | |
120 | -- | |
121 | 1.7.10.4 | |
122 |