summaryrefslogtreecommitdiffstats
path: root/arch/arm/oprofile
Commit message (Collapse)AuthorAgeFilesLines
...
* [ARM] 3295/1: Fix oprofile init return valueRuss Dill2006-02-011-2/+3
| | | | | | | | | | | Patch from Russ Dill The oprofile init code was broken in commit c6b9da. The new logic will always return -ENODEV. This fixes oprofile_arch_init to return 0 on success, and return the return value of spec->init() if applicable. Signed-off-by: Russ Dill <Russ.Dill@gmail.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [PATCH] mm: kill check_user_page_readableHugh Dickins2005-10-291-37/+9
| | | | | | | | | | | | | | | | | | | | | | | | | check_user_page_readable is a problematic variant of follow_page. It's used only by oprofile's i386 and arm backtrace code, at interrupt time, to establish whether a userspace stackframe is currently readable. This is problematic, because we want to push the page_table_lock down inside follow_page, and later split it; whereas oprofile is doing a spin_trylock on it (in the i386 case, forgotten in the arm case), and needs that to pin perhaps two pages spanned by the stackframe (which might be covered by different locks when we split). I think oprofile is going about this in the wrong way: it doesn't need to know the area is readable (neither i386 nor arm uses read protection of user pages), it doesn't need to pin the memory, it should simply __copy_from_user_inatomic, and see if that succeeds or not. Sorry, but I've not got around to devising the sparse __user annotations for this. Then we can eliminate check_user_page_readable, and return to a single follow_page without the __follow_page variants. Signed-off-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [ARM] 4/4 Combine oprofile common and init codeRussell King2005-10-283-52/+29
| | | | | | | There is nothing special about having the init code separate from the common code, so combine the two. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] 3/4 Rename common oprofile codeRussell King2005-10-283-48/+48
| | | | | | | | | | The common oprofile code assumes the name "PMU" (from Intel's performance management unit). This is misleading when we start adding oprofile support for other machine types which don't use the same terminology. Call it op_arm_* instead of pmu_*. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] 2/4 Fix oprofile suspend/resumeRussell King2005-10-281-3/+7
| | | | | | | | The oprofile suspend/resume was missing locking. If we failed to start oprofile on resume, we still reported that it was enabled. Instead, disable oprofile on error. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] 1/4 Move oprofile driver model codeRussell King2005-10-281-52/+47
| | | | Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [PATCH] ARM: 2838/1: Fix arm oprofile backtrace warningRichard Purdie2005-08-041-1/+1
| | | | | | | | | Patch from Richard Purdie Fix a typo causing a warning in the arm oprofile backtrace code. Signed-off-by: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [PATCH] ARM: 2761/1: OProfile: Add call graphing support for armRichard Purdie2005-06-284-1/+149
| | | | | | | | | | | | Patch from Richard Purdie Add functions to generate backtraces of both kernel and user processes which allows oprofile's call graphing functionality to be used on arm. This requires unstripped binaries/libs which use a frame pointer. Signed-off-by: Richard Purdie Signed-off-by: Zwane Mwaikambo <zwane@arm.linux.org.uk> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-167-0/+722
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!