aboutsummaryrefslogtreecommitdiff
path: root/include/asm-sh/delay.h
AgeCommit message (Collapse)Author
2008-03-06sh: Fix up the sh64 build.Paul Mundt
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2008-02-06Fix __const_udelay declaration and definition mismatchesJeff Dike
The declaration and implementation of __const_udelay use different names for the parameter on a number of architectures: include/asm-avr32/delay.h:15:extern void __const_udelay(unsigned long usecs); arch/avr32/lib/delay.c:39:inline void __const_udelay(unsigned long xloops) include/asm-sh/delay.h:15:extern void __const_udelay(unsigned long usecs); arch/sh/lib/delay.c:22:inline void __const_udelay(unsigned long xloops) include/asm-m32r/delay.h:15:extern void __const_udelay(unsigned long usecs); arch/m32r/lib/delay.c:58:void __const_udelay(unsigned long xloops) include/asm-x86/delay.h:16:extern void __const_udelay(unsigned long usecs); arch/x86/lib/delay_32.c:82:inline void __const_udelay(unsigned long xloops) arch/x86/lib/delay_64.c:46:inline void __const_udelay(unsigned long xloops) The units of the parameter isn't usecs, so that name is definitely wrong. It's also not exactly loops, so I suppose xloops is an OK name. This patch changes these names from usecs to xloops. Signed-off-by: Jeff Dike <jdike@linux.intel.com> Cc: Haavard Skinnemoen <hskinnemoen@atmel.com> Cc: Paul Mundt <lethal@linux-sh.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Hirokazu Takata <takata@linux-m32r.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-01-28sh: Tidy up lib64 udelay impl.Paul Mundt
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2005-04-16Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds
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!