user/sven/linux.git/arch/mips/lib/delay.c, branch v3.16.2

MIPS: __delay ABI-dependent subtraction simplification

2014-05-30T19:01:08Z

This small update to the previous fix to __delay removes a conditional around the ABI-dependent subtraction operation within an inline asm in favor to the standard LONG_SUBU macro. No change in code produced. Signed-off-by: Maciej W. Rozycki Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6703/ Signed-off-by: Ralf Baechle

MIPS: __delay CPU_DADDI_WORKAROUNDS bug fix

2014-05-12T22:29:36Z

With CPU_DADDI_WORKAROUNDS enabled __delay assembles with a macro in a branch delay slot: {standard input}: Assembler messages: {standard input}:18: Warning: Macro instruction expanded into multiple instructions in a branch delay slot and broken code results: 0000000000000000 <__delay>: 0: 1480ffff bnez a0,0 <__delay> 4: 24010001 li at,1 8: 0081202f dsubu a0,a0,at c: 03e00008 jr ra 10: 00000000 nop 14: 00000000 nop Consequently the function loops indefinitely, showing up prominently as a hang in the delay loop calibration at bootstrap. This change corrects the problem by forcing the immediate 1 into a register while keeping code produced identical where CPU_DADDI_WORKAROUNDS is disabled. Signed-off-by: Maciej W. Rozycki Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6669/ Signed-off-by: Ralf Baechle

MIPS: Whitespace cleanup.

2013-02-01T09:00:22Z

Having received another series of whitespace patches I decided to do this once and for all rather than dealing with this kind of patches trickling in forever. Signed-off-by: Ralf Baechle

MIPS: delay.c: Check BITS_PER_LONG instead of __SIZEOF_LONG__

2013-01-22T15:53:48Z

When building a 32-bit kernel for RBTX4927 with gcc version 4.1.2 20061115 (prerelease) (Ubuntu 4.1.1-21), I get: arch/mips/lib/delay.c:24:5: warning: "__SIZEOF_LONG__" is not defined As a consequence, __delay() always uses the 64-bit "dsubu" instruction. Replace the check for "__SIZEOF_LONG__ == 4" by "BITS_PER_LONG == 32" to fix this. Introduced by commit 5210edcd527773c227465ad18e416a894966324f [MIPS: Make __{,n,u}delay declarations match definitions and generic delay.h"] Signed-off-by: Geert Uytterhoeven Patchwork: https://patchwork.linux-mips.org/patch/4678/ Acked-by: David Daney Signed-off-by: Ralf Baechle

MIPS: Make __{,n,u}delay declarations match definitions and generic delay.h

2012-10-16T20:20:03Z

At some recent point arch/mips/include/asm/delay.h has started being included into csrc-octeon.c where the __?delay() functions are defined. This causes a compile failure due to conflicting declarations and definitions of the functions. It turns out that the generic definitions in arch/mips/lib/delay.c also conflict. Proposed fix: Declare the functions to take unsigned long parameters just like asm-generic (and x86) does. Update __delay to agree (__ndelay and __udelay need no change). Bonus: Get rid of 'inline' from __delay() definition, as it is globally visible, and the compiler should be making this decision itself (it does in fact inline the function without being told to). Signed-off-by: David Daney Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/4354/ Signed-off-by: Ralf Baechle

MIPS: delay: Fix use of current_cpu_data in preemptable code.

2010-04-12T16:26:09Z

This may lead to warnings like: BUG: using smp_processor_id() in preemptible [00000000] code: reboot/1989 caller is __udelay+0x14/0x70 Call Trace: [] dump_stack+0x8/0x34 [] debug_smp_processor_id+0xf4/0x110 [] __udelay+0x14/0x70 [] md_notify_reboot+0x12c/0x148 [] notifier_call_chain+0x64/0xc8 [] __blocking_notifier_call_chain+0x64/0xc0 [] kernel_restart_prepare+0x1c/0x38 [] kernel_restart+0x14/0x50 [] SyS_reboot+0x10c/0x1f0 [] handle_sysn32+0x44/0x84 Signed-off-by: Ralf Baechle

MIPS: Fix __ndelay build error and add 'ull' suffix for 32-bit kernel

2009-06-17T10:06:24Z

Signed-off-by: Atsushi Nemoto Signed-off-by: Ralf Baechle

MIPS: Outline udelay and fix a few issues.

2009-06-08T15:57:51Z

Outlining fixes the issue were on certain CPUs such as the R10000 family the delay loop would need an extra cycle if it overlaps a cacheline boundary. The rewrite also fixes build errors with GCC 4.4 which was changed in way incompatible with the kernel's inline assembly. Relying on pure C for computation of the delay value removes the need for explicit. The price we pay is a slight slowdown of the computation - to be fixed on another day. Signed-off-by: Ralf Baechle