[PATCH v3 4/4] iop: implement sched_clock()
dan.j.williams at intel.com
Tue Oct 27 19:43:18 EDT 2009
On Tue, 2009-10-27 at 03:52 -0700, Mikael Pettersson wrote:
> Thanks. Looks sane to me, although the extra load in sched_clock() does
> bother me.
I looked into it a bit more. The following patch also works for me and
diff --git a/arch/arm/mm/proc-xsc3.S b/arch/arm/mm/proc-xsc3.S
index 2028f37..fab134e 100644
@@ -396,7 +396,7 @@ __xsc3_setup:
orr r4, r4, #0x18 @ cache the page table in L2
mcr p15, 0, r4, c2, c0, 0 @ load page table pointer
- mov r0, #0 @ don't allow CP access
+ mov r0, #1 << 6 @ cp6 access for early sched_clock
mcr p15, 0, r0, c15, c1, 0 @ write CP access register
mrc p15, 0, r0, c1, c0, 1 @ get auxiliary control reg
I'll fold this into your patch.
> I wonder if the exception could be handled by an exception handler
> that just forces the return value to zero, similar to how the x86
> kernel handles bad get_user/put_user calls or accesses to potentially
> invalid (x86) MSRs?
This is what arch/arm/plat-iop/cp6.c does, it is just registered too
late to cover the early calls to sched_clock(), so we need to turn on
cp6 access early.
> Why whould anyone want to prevent the kernel from accessing cp6?
Kernel accesses are fine the trick is turning off access when returning
to userspace, and automatically turning access on when the kernel needs
it (via undefined instruction trap). Doing it dynamically eliminates
cp6 enable/disable code sprinkled throughout the kernel (commit
More information about the linux-arm-kernel