linux

mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-09-24 18:16:04 +00:00

53 lines

1.3 KiB

Raw Normal View History

Linux-2.6.12-rc2 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! 2005-04-16 15:20:36 -07:00








ndelay(): switch to C function to avoid 64-bit division We should be able to do ndelay(some_u64), but that can cause a call to __divdi3() to be emitted because the ndelay() macros does a divide. Fix it by switching to static inline which will force the u64 arg to be treated as an unsigned long. udelay() takes an unsigned long arg. [bunk@kernel.org: reported m68k build breakage] Cc: Adrian Bunk <bunk@kernel.org> Cc: Evgeniy Polyakov <johnpol@2ka.mipt.ru> Cc: Martin Michlmayr <tbm@cyrius.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Adrian Bunk <bunk@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 2008-03-04 14:28:45 -08:00

Linux-2.6.12-rc2 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! 2005-04-16 15:20:36 -07:00

















[POWERPC] Fix mdelay badness on shared processor partitions 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 <anton@samba.org> Signed-off-by: Paul Mackerras <paulus@samba.org> Acked-by: Andrew Morton <akpm@osdl.org> 2006-06-15 14:11:22 +10:00
Linux-2.6.12-rc2 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! 2005-04-16 15:20:36 -07:00





ndelay(): switch to C function to avoid 64-bit division We should be able to do ndelay(some_u64), but that can cause a call to __divdi3() to be emitted because the ndelay() macros does a divide. Fix it by switching to static inline which will force the u64 arg to be treated as an unsigned long. udelay() takes an unsigned long arg. [bunk@kernel.org: reported m68k build breakage] Cc: Adrian Bunk <bunk@kernel.org> Cc: Evgeniy Polyakov <johnpol@2ka.mipt.ru> Cc: Martin Michlmayr <tbm@cyrius.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Adrian Bunk <bunk@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 2008-03-04 14:28:45 -08:00




Linux-2.6.12-rc2 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! 2005-04-16 15:20:36 -07:00

53 lines 1.3 KiB Raw Normal View History

53 lines

1.3 KiB

Raw Normal View History