The non-scalar ktime_t implementation is basically a timespec
which has to be changed to support dates past 2038 on 32bit
systems.

This patch removes the non-scalar ktime_t implementation, forcing
the scalar s64 nanosecond version on all architectures.

This may have additional performance overhead on some 32bit
systems when converting between ktime_t and timespec structures,
however the majority of 32bit systems (arm and i386) were already
using scalar ktime_t, so no performance regressions will be seen
on those platforms.

On affected platforms, I'm open to finding optimizations, including
avoiding converting to timespecs where possible.

[ tglx: We can now cleanup the ktime_t.tv64 mess, but thats a
  different issue and we can throw a coccinelle script at it ]
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>

Rather then having two similar but totally different implementations
that provide timekeeping state to the hrtimer code, try to unify the
two implementations to be more simliar.

Thus this clarifies ktime_get_update_offsets to
ktime_get_update_offsets_now and changes get_xtime...  to
ktime_get_update_offsets_tick.
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>

Provide a default stub function instead of having the extra
conditional. Cuts binary size on a m68k build by ~100 bytes.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>

The code was only halfarsed converted to the new VSDO update mechanism
and still uses the inaccurate base value which lacks the fractional
part of xtime_nsec. Fix it up.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>

This script makes use of the udelay_test module to exercise udelay()
and ensure that it is delaying long enough (as compared to ktime).
Signed-off-by: NDavid Riley <davidriley@chromium.org>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>

Create a module that allows udelay() to be executed to ensure that
it is delaying at least as long as requested (with a little bit of
error allowed).

There are some configurations which don't have reliably udelay
due to using a loop delay with cpufreq changes which should use
a counter time based delay instead.  This test aims to identify
those configurations where timing is unreliable.
Signed-off-by: NDavid Riley <davidriley@chromium.org>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>

Merge branch 'clockevents/3.17' of git://git.linaro.org/people/daniel.lezcano/linux into timers/core

Pull clockevents from Danel Lezcano:
 * New timer driver for the Cirrus Logic CLPS711X SoC
 * New driver for the Mediatek SoC which includes:
 * A new function for of, acked by Rob Herring
 * Move the PXA driver to drivers/clocksource, add DT support
 * Optimization of the exynos_mct driver
 * DT support for the renesas timers family.
 * Some Kconfig and driver fixlets

The MCT has a nice 64-bit counter.  That means that we _can_ register
as a 64-bit clocksource and sched_clock.  ...but that doesn't mean we
should.

The 64-bit counter is read by reading two 32-bit registers.  That
means reading needs to be something like:
- Read upper half
- Read lower half
- Read upper half and confirm that it hasn't changed.

That wouldn't be terrible, but:
- THe MCT isn't very fast to access (hundreds of nanoseconds).
- The clocksource is queried _all the time_.

In total system profiles of real workloads on ChromeOS, we've seen
exynos_frc_read() taking 2% or more of CPU time even after optimizing
the 3 reads above to 2 (see below).

The MCT is clocked at ~24MHz on all known systems.  That means that
the 32-bit half of the counter rolls over every ~178 seconds.  This
inspired an optimization in ChromeOS to cache the upper half between
calls, moving 3 reads to 2.  ...but we can do better!  Having a 32-bit
timer that flips every 178 seconds is more than sufficient for Linux.
Let's just use the lower half of the MCT.

Times on 5420 to do 1000000 gettimeofday() calls from userspace:
* Original code:                      1323852 us
* ChromeOS cache upper half:          1173084 us
* ChromeOS + ldmia to optimize:       1045674 us
* Use lower 32-bit only (this code):  1014429 us

As you can see, the time used doesn't increase linearly with the
number of reads and we can make 64-bit work almost as fast as 32-bit
with a bit of assembly code.  But since there's no real gain for
64-bit, let's go with the simplest and fastest implementation.

Note: with this change roughly half the time for gettimeofday() is
spent in exynos_frc_read().  The rest is timer / system call overhead.

Also note: this patch disables the use of the MCT on ARM64 systems
until we've sorted out how to make "cycles_t" always 32-bit.  Really
ARM64 systems should be using arch timers anyway.
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Acked-by Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

Using the __raw functions is discouraged.  Update the file to
consistently use the proper functions.
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

As clocksource pxa_timer was moved to clocksource framework, the
pxa_timer initialization needs to be a bit amended, to pass the
necessary informations to clocksource, ie :
 - the timer interrupt (mach specific)
 - the timer registers base (ditto)
 - the timer clockrate
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

Select CLKSRC_OF for PXA architectures.
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

Add device-tree support to PXA platforms.
The driver still needs to maintain backward non device-tree
compatibility as well, which implies :
 - a non device-tree init function
 - a static registers base address in the driver
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

Move time.c from arch/arm/mach-pxa/time.c to
drivers/clocksource/pxa_timer.c.
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

This patch adds DT binding documentation for the Cirrus Logic
CLPS711X-based CPUs clocksource subsystem.
Signed-off-by: NAlexander Shiyan <shc_work@mail.ru>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

This adds the clocksource driver for Cirrus Logic CLPS711X series SoCs.
Designed primarily for migration CLPS711X subarch for multiplatform & DT,
for this as the "OF" and "non-OF" calls implemented.
Signed-off-by: NAlexander Shiyan <shc_work@mail.ru>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

In the clocksource driver, we didn't explicitly enable the clock. it makes the
clk reference counter wrong. We didn't encounter any hang issue because the
tick's clock input has been open and is shared by some other hardware
components, but if we don't enable those components in kernel, in the stage of
disabling unused clk in kernel boot, Linux tick hangs.

This patch fixes it. it does an explicit prepare and enable to the clock input,
and increases the usage counter of the clk.
Signed-off-by: NZhiwu Song <Zhiwu.Song@csr.com>
Signed-off-by: NBarry Song <Baohua.Song@csr.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

In 'em_sti.c', it will call devm_ioremap_resource() which need
HAS_IOMEM. So need let EM_TIMER_STI depend on HAS_IOMEM, too.

The related error (with allmodconfig under score):

  LD      init/built-in.o
em_sti.c:(.text.em_sti_probe+0x84): undefined reference to `devm_ioremap_resource'
make: *** [vmlinux] Error 1
Signed-off-by: NChen Gang <gang.chen.5i5j@gmail.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

Signed-off-by: NMatthias Brugger <matthias.bgg@gmail.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

Add binding documentation for the General Purpose Timer driver of
the Mediatek SoCs.
Signed-off-by: NMatthias Brugger <matthias.bgg@gmail.com>
Acked-by: NSören Brinkmann <soren.brinkmann@xilinx.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

This patch adds a clock source and clock event for the timer found
on the Mediatek SoCs.

The Mediatek General Purpose Timer block provides five 32 bit timers and
one 64 bit timer.

Two 32 bit timers are used by this driver:
TIMER1: clock events supporting periodic and oneshot events
TIMER2: clock source configured as a free running counter

The General Purpose Timer block can be run with two clocks. A 13 MHz system
clock and the RTC clock running at 32 KHz. This implementation uses the system
clock with no clock source divider.

The interrupts are shared between the different timers and have to be read back
from a register. We just enable one interrupt for the clock event. The clock
event timer is used by all cores.
Signed-off-by: NMatthias Brugger <matthias.bgg@gmail.com>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

A call to of_iomap does not request the memory region. This patch adds the
function of_io_request_and_map which requests the memory region before
mapping it.
Signed-off-by: NMatthias Brugger <matthias.bgg@gmail.com>
Suggested-by: NThomas Gleixner <tglx@linutronix.de>
Suggested-by: NRob Herring <robh@kernel.org>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

It should be "MTU2" instead of "TMU2"
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: NWolfram Sang <wsa@sang-engineering.com>
Acked-by: NSimon Horman <horms+renesas@verge.net.au>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

The read() of timerfd files allows to fetch the number of timer ticks
while there is no way to set it back from userspace.

To restore the timer's state as it was at checkpoint moment we need
a path to bring @ticks back. Initially I thought about writing ticks
back via write() interface but it seems such API is somehow obscure.

Instead implement timerfd_ioctl() method with TFD_IOC_SET_TICKS
command which allows to adjust @ticks into non-zero value waking
up the waiters.

I wrapped code with CONFIG_CHECKPOINT_RESTORE which can be
dropped off if there users except c/r camp appear.

v2 (by akpm@):
 - Use define timerfd_ioctl NULL for non c/r config

v3:
 - Use copy_from_user for @ticks fetching since
   not all arch support get_user for 8 byte argument
Signed-off-by: NCyrill Gorcunov <gorcunov@openvz.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Andrey Vagin <avagin@openvz.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Christopher Covington <cov@codeaurora.org>
Cc: Pavel Emelyanov <xemul@parallels.com>
Cc: Vladimir Davydov <vdavydov@parallels.com>
Link: http://lkml.kernel.org/r/20140715215703.285617923@openvz.orgSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

Signed-off-by: NCyrill Gorcunov <gorcunov@openvz.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Andrey Vagin <avagin@openvz.org>
Cc: Pavel Emelyanov <xemul@parallels.com>
Cc: Vladimir Davydov <vdavydov@parallels.com>
Link: http://lkml.kernel.org/r/20140715215703.199905126@openvz.orgSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

For checkpoint/restore of timerfd files we need to know how exactly
the timer were armed, to be able to recreate it on restore stage.
Thus implement show_fdinfo method which provides enough information
for that.

One of significant changes I think is the addition of @settime_flags
member. Currently there are two flags TFD_TIMER_ABSTIME and
TFD_TIMER_CANCEL_ON_SET, and the second can be found from
@might_cancel variable but in case if the flags will be extended
in future we most probably will have to somehow remember them
explicitly anyway so I guss doing that right now won't hurt.

To not bloat the timerfd_ctx structure I've converted @expired
to short integer and defined @settime_flags as short too.

v2 (by avagin@, vdavydov@ and tglx@):

 - Add it_value/it_interval fields
 - Save flags being used in timerfd_setup in context

v3 (by tglx@):
 - don't forget to use CONFIG_PROC_FS

v4 (by akpm@):
 -Use define timerfd_show NULL for non c/r config
Signed-off-by: NCyrill Gorcunov <gorcunov@openvz.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Andrey Vagin <avagin@openvz.org>
Cc: Pavel Emelyanov <xemul@parallels.com>
Cc: Vladimir Davydov <vdavydov@parallels.com>
Link: http://lkml.kernel.org/r/20140715215703.114365649@openvz.orgSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

Reason: Bring in upstream modifications, so the pending changes which
depend on them can be queued.

Pull ext4 bugfixes from Ted Ts'o:
 "More bug fixes for ext4 -- most importantly, a fix for a bug
  introduced in 3.15 that can end up triggering a file system corruption
  error after a journal replay.

  It shouldn't lead to any actual data corruption, but it is scary and
  can force file systems to be remounted read-only, etc"

* tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
  ext4: fix potential null pointer dereference in ext4_free_inode
  ext4: fix a potential deadlock in __ext4_es_shrink()
  ext4: revert commit which was causing fs corruption after journal replays
  ext4: disable synchronous transaction batching if max_batch_time==0
  ext4: clarify ext4_error message in ext4_mb_generate_buddy_error()
  ext4: clarify error count warning messages
  ext4: fix unjournalled bg descriptor while initializing inode bitmap

Pull clock driver fixes from Mike Turquette:
 "This batch of fixes is for a handful of clock drivers from Allwinner,
  Samsung, ST & TI.  Most of them are of the "this hardware won't work
  without this fix" variety, including patches that fix platforms that
  did not boot under certain configurations.  Other fixes are the result
  of changes to the clock core introduced in 3.15 that had subtle
  impacts on the clock drivers.

  There are no fixes to the clock framework core in this pull request"

* tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mike.turquette/linux:
  clk: spear3xx: Set proper clock parent of uart1/2
  clk: spear3xx: Use proper control register offset
  clk: qcom: HDMI source sel is 3 not 2
  clk: sunxi: fix devm_ioremap_resource error detection code
  clk: s2mps11: Fix double free corruption during driver unbind
  clk: ti: am43x: Fix boot with CONFIG_SOC_AM33XX disabled
  clk: exynos5420: Remove aclk66_peric from the clock tree description
  clk/exynos5250: fix bit number for tv sysmmu clock
  clk: s3c64xx: Hookup SPI clocks correctly
  clk: samsung: exynos4: Remove SRC_MASK_ISP gates
  clk: samsung: add more aliases for s3c24xx
  clk: samsung: fix several typos to fix boot on s3c2410
  clk: ti: set CLK_SET_RATE_NO_REPARENT for ti,mux-clock
  clk: ti: am43x: Fix boot with CONFIG_SOC_AM33XX disabled
  clk: ti: dra7: return error code in failure case
  clk: ti: apll: not allocating enough data

Pull ARM SoC fixes from Olof Johansson:
 "This week's arm-soc fixes:

   - Another set of OMAP fixes
     * Clock fixes
     * Restart handling
     * PHY regulators
     * SATA hwmod data for DRA7
     + Some trivial fixes and removal of a bit of dead code
   - Exynos fixes
     * A bunch of clock fixes
     * Some SMP fixes
     * Exynos multi-core timer: register as clocksource and fix ftrace.
     + a few other minor fixes

  There's also a couple more patches, and at91 fix for USB caused by
  common clock conversion, and more MAINTAINERS entries for shmobile.

  We're definitely switching to only regression fixes from here on out,
  we've been a little less strict than usual up until now"

* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (26 commits)
  ARM: at91: at91sam9x5: add clocks for usb device
  ARM: EXYNOS: Register cpuidle device only on exynos4210 and 5250
  ARM: dts: Add clock property for mfc_pd in exynos5420
  clk: exynos5420: Add IDs for clocks used in PD mfc
  ARM: EXYNOS: Add support for clock handling in power domain
  ARM: OMAP2+: Remove non working OMAP HDMI audio initialization
  ARM: imx: fix shared gate clock
  ARM: dts: Update the parent for Audss clocks in Exynos5420
  ARM: EXYNOS: Update secondary boot addr for secure mode
  ARM: dts: Fix TI CPSW Phy mode selection on IGEP COM AQUILA.
  ARM: dts: am335x-evmsk: Enable the McASP FIFO for audio
  ARM: dts: am335x-evm: Enable the McASP FIFO for audio
  ARM: OMAP2+: Make GPMC skip disabled devices
  ARM: OMAP2+: create dsp device only on OMAP3 SoCs
  ARM: dts: dra7-evm: Make VDDA_1V8_PHY supply always on
  ARM: DRA7/AM43XX: fix header definition for omap44xx_restart
  ARM: OMAP2+: clock/dpll: fix _dpll_test_fint arithmetics overflow
  ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss
  ARM: DRA7: hwmod: Fixup SATA hwmod
  ARM: OMAP3: PRM/CM: Add back macros used by TI DSP/Bridge driver
  ...

Pull ARM fixes from Russell King:
 "Another round of fixes for ARM:
   - a set of kprobes fixes from Jon Medhurst
   - fix the revision checking for the L2 cache which wasn't noticed to
     have been broken"

* 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
  ARM: l2c: fix revision checking
  ARM: kprobes: Fix test code compilation errors for ARMv4 targets
  ARM: kprobes: Disallow instructions with PC and register specified shift
  ARM: kprobes: Prevent known test failures stopping other tests running

Pull m68k fixes from Geert Uytterhoeven:
 "Summary:
  - Fix for a boot regression introduced in v3.16-rc1,
  - Fix for a build issue in -next"

Christoph Hellwig questioned why mach_random_get_entropy should be
exported to modules, and Geert explains that random_get_entropy() is
called by at least the crypto layer and ends up using it on m68k.  On
most other architectures it just uses get_cycles() (which is typically
inlined and doesn't need exporting),

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k:
  m68k: Export mach_random_get_entropy to modules
  m68k: Fix boot regression on machines with RAM at non-zero

Pull parisc fixes from Helge Deller:
 "The major patch in here is one which fixes the fanotify_mark() syscall
  in the compat layer of the 64bit parisc kernel.  It went unnoticed so
  long, because the calling syntax when using a 64bit parameter in a
  32bit syscall is quite complex and even worse, it may be even
  different if you call syscall() or the glibc wrapper.  This patch
  makes the kernel accept the calling convention when called by the
  glibc wrapper.

  The other two patches are trivial and remove unused headers, #includes
  and adds the serial ports of the fastest C8000 workstation to the
  parisc-kernel internal hardware database"

* 'parisc-3.16-5' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
  parisc: drop unused defines and header includes
  parisc: fix fanotify_mark() syscall on 32bit compat kernel
  parisc: add serial ports of C8000/1GHz machine to hardware database

The uarts only work when the parent is ras_ahb_clk. The stale 3.5
based ST tree does this in the board file.

Add it to the clk init function. Not pretty, but the mess there is
amazing anyway.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

The control register is at offset 0x10, not 0x0. This is wreckaged
since commit 5df33a62 (SPEAr: Switch to common clock framework).
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

Signed-off-by: NHelge Deller <deller@gmx.de>
Cc: stable@vger.kernel.org # 3.13+

On parisc we can not use the existing compat implementation for fanotify_mark()
because for the 64bit mask parameter the higher and lower 32bits are ordered
differently than what the compat function expects from big endian
architectures.

Specifically:
It finally turned out, that on hppa we end up with different assignments
of parameters to kernel arguments depending on if we call the glibc
wrapper function
 int fanotify_mark (int __fanotify_fd, unsigned int __flags,
                    uint64_t __mask, int __dfd, const char *__pathname);
or directly calling the syscall manually
 syscall(__NR_fanotify_mark, ...)

Reason is, that the syscall() function is implemented as C-function and
because we now have the sysno as first parameter in front of the other
parameters the compiler will unexpectedly add an empty paramenter in
front of the u64 value to ensure the correct calling alignment for 64bit
values.
This means, on hppa you can't simply use syscall() to call the kernel
fanotify_mark() function directly, but you have to use the glibc
function instead.

This patch fixes the kernel in the hppa-arch specifc coding to adjust
the parameters in a way as if userspace calls the glibc wrapper function
fanotify_mark().
Signed-off-by: NHelge Deller <deller@gmx.de>
Cc: stable@vger.kernel.org # 3.13+

Signed-off-by: NHelge Deller <deller@gmx.de>
Cc: stable@vger.kernel.org # 3.13+

Pull slave-dmaengine fixes from Vinod Koul:
 "We have two small fixes.  First one from Daniel to handle 0-length
  packets for usb cppi dma.  Second by Russell for imx-sdam cyclic
  residue reporting"

* 'fixes' of git://git.infradead.org/users/vkoul/slave-dma:
  Update imx-sdma cyclic handling to report residue
  dma: cppi41: handle 0-length packets