- 19 3月, 2006 1 次提交
-
-
由 Ralf Baechle 提交于
From Dave Johnson <djohnson+linuxmips@sw.starentnetworks.com>: sb1250_gettimeoffset() simply reads the current cpu 0 timer remaining value, however once this counter reaches 0 and the interrupt is raised, it immediately resets and begins to count down again. If sb1250_gettimeoffset() is called on cpu 1 via do_gettimeofday() after the timer has reset but prior to cpu 0 processing the interrupt and taking write_seqlock() in timer_interrupt() it will return a full value (or close to it) causing time to jump backwards 1ms. Once cpu 0 handles the interrupt and timer_interrupt() gets far enough along it will jump forward 1ms. Fix this problem by implementing mips_hpt_*() on sb1250 using a spare timer unrelated to the existing periodic interrupt timers. It runs at 1Mhz with a full 23bit counter. This eliminated the custom do_gettimeoffset() for sb1250 and allowed use of the generic fixed_rate_gettimeoffset() using mips_hpt_*() and timerhi/timerlo. Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
- 30 10月, 2005 3 次提交
-
-
由 Andrew Isaacson 提交于
- Kconfig and Makefile changes - arch/mips/sibyte/bcm1480/ - changes to sibyte common code to support 1480 Signed-Off-By: NAndy Isaacson <adi@broadcom.com> Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Ralf Baechle 提交于
will do that itself iff needed. Fix format string. Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Ralf Baechle 提交于
initialization actually useful and as is certainly unmergable with upstream. 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!
-