- 14 2月, 2007 1 次提交
-
-
由 Ralf Baechle 提交于
Now that finally all supported versions of binutils have functioning support for .subsection use .subsection to tweak the branch prediction I did not modify the R10000 errata variants because it seems unclear if this will invalidate the workaround which actually relies on the cheesy prediction of branch likely to cause a misspredict if the sc was successful. Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
- 05 12月, 2006 1 次提交
-
-
由 Ralf Baechle 提交于
Also the R4000 / R4600 LL/SC instructions imply a sync so no explicit sync needed. Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
- 30 11月, 2006 2 次提交
-
-
由 Ralf Baechle 提交于
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Ralf Baechle 提交于
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
- 14 7月, 2006 1 次提交
-
-
由 Ralf Baechle 提交于
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
- 27 4月, 2006 1 次提交
-
-
由 Atsushi Nemoto 提交于
With recent rewrite for generic bitops, fls() for 32bit kernel with MIPS64_CPU is broken. Also, ffs(), fls() should be defined the same way as the libc and compiler built-in routines (returns int instead of unsigned long). Signed-off-by: NAtsushi Nemoto <anemo@mba.ocn.ne.jp> Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
- 26 4月, 2006 1 次提交
-
-
由 David Woodhouse 提交于
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
-
- 27 3月, 2006 2 次提交
-
-
由 Akinobu Mita 提交于
- remove __{,test_and_}{set,clear,change}_bit() and test_bit() - unless defined(CONFIG_CPU_MIPS32) or defined(CONFIG_CPU_MIPS64) - remove __ffs() - remove ffs() - remove ffz() - remove fls() - remove fls64() - remove find_{next,first}{,_zero}_bit() - remove sched_find_first_bit() - remove generic_hweight64() - remove generic_hweight{32,16,8}() - remove ext2_{set,clear,test,find_first_zero,find_next_zero}_bit() - remove ext2_{set,clear}_bit_atomic() - remove minix_{test,set,test_and_clear,test,find_first_zero}_bit() Signed-off-by: NAkinobu Mita <mita@miraclelinux.com> Cc: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Akinobu Mita 提交于
Bitmap functions for the minix filesystem and the ext2 filesystem except ext2_set_bit_atomic() and ext2_clear_bit_atomic() do not require the atomic guarantees. But these are defined by using atomic bit operations on several architectures. (cris, frv, h8300, ia64, m32r, m68k, m68knommu, mips, s390, sh, sh64, sparc, sparc64, v850, and xtensa) This patch switches to non atomic bit operation. Signed-off-by: NAkinobu Mita <mita@miraclelinux.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 07 2月, 2006 1 次提交
-
-
由 Ralf Baechle 提交于
fls was the only called of flz, so fold flz into fls, same for the __ilog2 call. Delete the now unused flz function. Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
- 04 1月, 2006 1 次提交
-
-
由 Stephen Hemminger 提交于
Signed-off-by: NStephen Hemminger <shemminger@osdl.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 30 10月, 2005 4 次提交
-
-
由 Ralf Baechle 提交于
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Ralf Baechle 提交于
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Maciej W. Rozycki 提交于
for assembling ll/sc sequences to avoid problems with 64-bit configurations. Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Maciej W. Rozycki 提交于
builds even for processors that don't support the instructions. Plus minor formatting fixes. Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
- 05 9月, 2005 2 次提交
-
-
由 Ralf Baechle 提交于
Signed-off-by: NRalf Baechle <ralf@linux-mips.org> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Ralf Baechle 提交于
Start cleaning 32-bit vs. 64-bit configuration. Signed-off-by: NRalf Baechle <ralf@linux-mips.org> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus 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!
-