linux-stable.git/arch/parisc/kernel/time.c, branch linux-4.7.y

parisc: Fix automatic selection of cr16 clocksource

2016-09-07T06:34:45+00:00

commit ae141830b118c3fb5b7eab6fa7c8ab7b7224b0a4 upstream.

Commit 54b66800907 (parisc: Add native high-resolution sched_clock()
implementation) added support to use the CPU-internal cr16 counters as reliable
clocksource with the help of HAVE_UNSTABLE_SCHED_CLOCK.

Sadly the commit missed to remove the hack which prevented cr16 to become the
default clocksource even on SMP systems.

Signed-off-by: Helge Deller 
Signed-off-by: Greg Kroah-Hartman

parisc: Fix printk time during boot

2016-06-05T06:45:09+00:00

Avoid showing invalid printk time stamps during boot.

Signed-off-by: Helge Deller 
Reviewed-by: Aaro Koskinen

parisc: Add native high-resolution sched_clock() implementation

2016-05-22T19:39:25+00:00

Add a native implementation for the sched_clock() function which utilizes the
processor-internal cycle counter (Control Register 16) as high-resolution time
source.

With this patch we now get much more fine-grained resolutions in various
in-kernel time measurements (e.g. when viewing the function tracing logs), and
probably a more accurate scheduling on SMP systems.

There are a few specific implementation details in this patch:

1. On a 32bit kernel we emulate the higher 32bits of the required 64-bit
resolution of sched_clock() by increasing a per-cpu counter at every
wrap-around of the 32bit cycle counter.

2. In a SMP system, the cycle counters of the various CPUs are not syncronized
(similiar to the TSC in a x86_64 system). To cope with this we define
HAVE_UNSTABLE_SCHED_CLOCK and let the upper layers do the adjustment work.

3. Since we need HAVE_UNSTABLE_SCHED_CLOCK, we need to provide a cmpxchg64()
function even on a 32-bit kernel.

4. A 64-bit SMP kernel which is started on a UP system will mark the
sched_clock() implementation as "stable", which means that we don't expect any
jumps in the returned counter. This is true because we then run only on one
CPU.

Signed-off-by: Helge Deller

parisc: Use platform_device_register_simple("rtc-generic")

2015-09-08T15:53:48+00:00

Signed-off-by: Helge Deller

parisc: Drop CONFIG_SMP around update_cr16_clocksource()

2015-09-08T15:53:03+00:00

No need to use CONFIG_SMP around update_cr16_clocksource(). It checks for
num_online_cpus() beeing greater than 1, which is always 1 in UP builds.

Signed-off-by: Helge Deller

parisc: move definition of PAGE0 to asm/page.h

2012-05-10T22:12:08+00:00

This was defined in asm/pdc.h which needs to include asm/page.h for
__PAGE_OFFSET. This leads to an include loop so that page.h eventually will
include pdc.h again. While this is no problem because of header guards, it is
a problem because some symbols may be undefined. Such an error is this:

In file included from include/linux/bitops.h:35:0,
                 from include/asm-generic/getorder.h:7,
                 from arch/parisc/include/asm/page.h:162,
                 from arch/parisc/include/asm/pdc.h:346,
                 from arch/parisc/include/asm/processor.h:16,
                 from arch/parisc/include/asm/spinlock.h:6,
                 from arch/parisc/include/asm/atomic.h:20,
                 from include/linux/atomic.h:4,
                 from include/linux/sysfs.h:20,
                 from include/linux/kobject.h:21,
                 from include/linux/device.h:17,
                 from include/linux/eisa.h:5,
                 from arch/parisc/kernel/pci.c:11:
arch/parisc/include/asm/bitops.h: In function ‘set_bit’:
arch/parisc/include/asm/bitops.h:82:2: error: implicit declaration of function ‘_atomic_spin_lock_irqsave’ [-Werror=implicit-function-declaration]
arch/parisc/include/asm/bitops.h:84:2: error: implicit declaration of function ‘_atomic_spin_unlock_irqrestore’ [-Werror=implicit-function-declaration]

Signed-off-by: Rolf Eike Beer 
Signed-off-by: Linus Torvalds

clocksource: parisc: Convert to clocksource_register_hz/khz

2011-11-22T03:01:02+00:00

This converts the parisc clocksources to use clocksource_register_hz/khz

This is untested, so any assistance in testing would be appreciated!

CC: Kyle McMartin 
CC: Thomas Gleixner 
Signed-off-by: John Stultz

parisc: Switch do_timer() to xtime_update()

2011-01-31T13:55:46+00:00

xtime_update() takes the xtime_lock itself.

Signed-off-by: Torben Hohn 
Cc: hch@infradead.org
Cc: Peter Zijlstra 
Cc: johnstul@us.ibm.com
Cc: Helge Deller 
Cc: "James E.J. Bottomley" 
Cc: Kyle McMartin 
Cc: yong.zhang0@gmail.com
LKML-Reference: <20110127150017.23248.22559.stgit@localhost>
Signed-off-by: Thomas Gleixner

parisc: Convert to read/update_persistent_clock

2010-03-06T22:54:10+00:00

This patch converts the parisc architecture to use the generic
read_persistent_clock and update_persistent_clock interfaces, reducing
the amount of arch specific code we have to maintain, and allowing for
further cleanups in the future.

I have not built or tested this patch, so help from arch maintainers
would be appreciated.

Signed-off-by: John Stultz 
Acked-by: Helge Deller 
Signed-off-by: Kyle McMartin

parisc: fix "delay!" timer handling

2009-07-03T03:34:09+00:00

Rewrote timer_interrupt() to properly handle the "delayed!" case.

If we used floating point math to compute the number of ticks that had
elapsed since the last timer interrupt, it could take up to 12K cycles
(emperical!) to handle the interrupt. Existing code assumed it would
never take more than 8k cycles. We end up programming Interval Timer
to a value less than "current" cycle counter.  Thus have to wait until
Interval Timer "wrapped" and would then get the "delayed!" printk that
I moved below.

Since we don't really know what the upper limit is, I prefer to read
CR16 again after we've programmed it to make sure we won't have to
wait for CR16 to wrap.

Further, the printk was between reading CR16 (cycle couner) and writing CR16
(the interval timer). This would cause us to continue to set the interval
timer to a value that was "behind" the cycle counter. Rinse and repeat.
So no printk's between reading CR16 and setting next interval timer.

Tested on A500 (550 Mhz PA8600).

Signed-off-by: Grant Grundler 
Tested-by: Kyle McMartin 
Signed-off-by: Kyle McMartin 

----
Kyle, Helge, and other parisc's,
Please test on 32-bit before committing.
I think I have it right but recognize I might not.

TODO: I wanted to use "do_div()" in order to get both remainder
and value back with one division op. That should help with the
latency alot but can be applied seperately from this patch.

thanks,
grant