21 Jun, 2006
1 commit
-
On partitioned PPC64 systems where a partition is given 1/10 of a
processor, we have seen mdelay() delaying for 10 times longer than it
should. The reason is that the generic mdelay(n) does n delays of 1
millisecond each. However, with 1/10 of a processor, we only get a
one-millisecond timeslice every 10ms. Thus each 1 millisecond delay
loop ends up taking 10ms elapsed time.The solution is just to use the PPC64 udelay function, which uses the
timebase to ensure that the delay is based on elapsed time rather than
how much processing time the partition has been given. (Yes, the
generic mdelay uses the PPC64 udelay, but the problem is that the
start time gets reset every millisecond, and each time it gets reset
we lose another 9ms.)Signed-off-by: Anton Blanchard
Signed-off-by: Paul Mackerras
Acked-by: Andrew Morton
09 Jan, 2006
1 commit
-
include/asm-ppc/ had #ifdef __KERNEL__ in all header files that
are not meant for use by user space, include/asm-powerpc does
not have this yet.This patch gets us a lot closer there. There are a few cases
where I was not sure, so I left them out. I have verified
that no CONFIG_* symbols are used outside of __KERNEL__
any more and that there are no obvious compile errors when
including any of the headers in user space libraries.Signed-off-by: Arnd Bergmann
Signed-off-by: Paul Mackerras
18 Nov, 2005
1 commit
-
My earlier merge of delay.h introduced a timebase-based udelay for
32-bit machines but also broke the 601, which doesn't have the
timebase register. This fixes it by using the 601's RTC register on
the 601, and also moves __delay() and udelay() to be out-of-line in
arch/powerpc/kernel/time.c. These functions aren't really performance
critical, after all.Signed-off-by: Paul Mackerras
14 Nov, 2005
1 commit
-
... and also delete some that are no longer used because we already
had an include/asm-powerpc version of the header.Signed-off-by: Paul Mackerras