We have no guarantee by the generic time code that the timer is stopped
when the ->next_event method is called.  Modifying the Timer Initial Count
register while the timer is enabled has UNPREDICTABLE effect according to
the BCM1250/BCM1125/BCM1125H User Manual.  So stop the timer before
reprogramming.

This is a paranoia fix; no ill effects have been observed previously.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

For the old minimum of a single tick a value of zero would be programmed
into the init value register which in the BCM1250/BCM1125/BCM1125H User
Manual in the Timer Special Cases section is documented to have
UNPREDICTABLE effect.

Observable sympthoms of this bug were hangs of several seconds on the
console during bootup and later if both dyntick and highres timer options
were activated.

In theory contiguous mode of the timers is also affected but in an act of
hopeless lack of realism I'll assume nobody will ever configure a KERNEL
for HZ > 500kHz but if so I leave that to evolution to sort out.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Or strange things will happen.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

They break the timer interrupt initialization and only seem to be a kludge
for initialization happening in the wrong order.  Further testing done by
Thiemo confirms the suspicion that the other invocations also seem to have
useless.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

The BCM148 has 4 cores but there are also just 4 generic timers available
so use the ZBbus cycle counter instead of it.  In addition the ZBbus
counter also offers a much higher resolution and 64-bit counting so I'm
considering a later complete conversion to it once I figure out if all
members of the Sibyte SOC family support it - the docs seem to agree but
the headers files seem to disagree ...
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Fix some typo introduced on clockevent conversion.
Signed-off-by: NAtsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Make clocksource_mips public and get rid of mips_hpt_read,
mips_hpt_mask.
Signed-off-by: NAtsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NNicolas Kaiser <nikai@nikai.net>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Since we already moved to GENERIC_TIME, we should implement alternatives
of old do_gettimeoffset routines to get sub-jiffies resolution from
gettimeofday().  This patch includes:

 * MIPS clocksource support (based on works by Manish Lachwani).
 * remove unused gettimeoffset routines and related codes.
 * remove unised 64bit do_div64_32().
 * simplify mips_hpt_init. (no argument needed, __init tag)
 * simplify c0_hpt_timer_init. (no need to write to c0_count)
 * remove some hpt_init routines.
 * mips_hpt_mask variable to specify bitmask of hpt value.
 * convert jmr3927_do_gettimeoffset to jmr3927_hpt_read.
 * convert ip27_do_gettimeoffset to ip27_hpt_read.
 * convert bcm1480_do_gettimeoffset to bcm1480_hpt_read.
 * simplify sb1250 hpt functions. (no need to subtract and shift)
Signed-off-by: NAtsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NJörn Engel <joern@wohnheim.fh-wedel.de>
Signed-off-by: NAdrian Bunk <bunk@stusta.de>

Running a UP kernel on a bcm1480 board, I get nonsensical timing
results, like this:
release@unknown:~/tmp$ time ./a.out
real    0m22.906s
user    0m45.792s
sys     0m0.010s
According to my watch, this program took 23 seconds to run, so the real
time clock is OK.  It is process accounting that is broken.

I tracked this down to a problem with the function
bcm1480_timer_interrupt in the file sibyte/bcm1480/time.c.  This
function calls ll_timer_interrupt for cpu0, and ll_local_timer_interrupt
for all cpus.  However, both of these functions do process accounting.
Thus processes running on cpu0 end up with doubled times.  This is very
obvious in a UP kernel where all processes run on cpu0.

The correct way to do this is to only call ll_local_timer interrupt if
this is not cpu0.  This can be seen in the mips-board/generic/time.c
file, and also in the sibyte/sb1250/time.c file, both of which handle
this correctly.  I fixed the bcm1480/time.c file by copying over the
correct code from the sb1250/time.c file.

With this fix, I now get sensible results.
release@unknown:~/tmp$ time ./a.out
real    0m22.903s
user    0m22.894s
sys     0m0.006s
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

    
 - 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>

Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

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!