The CLOCKSOURCE_OF_DECLARE macro is used widely for the timers to declare the
clocksource at early stage. However, this macro is also used to initialize
the clockevent if any, or the clockevent only.

It was originally suggested to declare another macro to initialize a
clockevent, so in order to separate the two entities even they belong to the
same IP. This was not accepted because of the impact on the DT where splitting
a clocksource/clockevent definition does not make sense as it is a Linux
concept not a hardware description.

On the other side, the clocksource has not interrupt declared while the
clockevent has, so it is easy from the driver to know if the description is
for a clockevent or a clocksource, IOW it could be implemented at the driver
level.

So instead of dealing with a named clocksource macro, let's use a more generic
one: TIMER_OF_DECLARE.

The patch has not functional changes.
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NNeil Armstrong <narmstrong@baylibre.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NMatthias Brugger <matthias.bgg@gmail.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>

After discussing it, this feature is dropped as it is not considered
adequate:

	https://patchwork.kernel.org/patch/9639317/

There is no user of this macro yet, so there is no impact on the drivers.

This reverts commit 376bc271.

Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

The recent changes made the fttmr010 to be more generic and support different
timers with a very few differences like moxart or aspeed.

The aspeed timer uses a countdown and there is a test against the aspeed2400
compatible string to set a flag.

With the previous patch, we added the aspeed2500 compatible string but without
taking care of setting the countdown flag.

Fix this by specifiying a init function and pass the aspeed flag to a common
init function.
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Tested-by: NAndrew Jeffery <andrew@aj.id.au>
Reviewed-by: NAndrew Jeffery <andrew@aj.id.au>
Acked-by: NJoel Stanley <joel@jms.id.au>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

Also clean up space-before-tab issues in the documentation.
Signed-off-by: NAndrew Jeffery <andrew@aj.id.au>
Acked-by: NJoel Stanley <joel@jms.id.au>
Acked-by: NRob Herring <robh@kernel.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

This merges the Moxa Art timer driver into the Faraday FTTMR010
driver and replaces all Kconfig symbols to use the Faraday
driver instead. We are now so similar that the drivers can
be merged by just adding a few lines to the Faraday timer.

Differences:

- The Faraday driver explicitly sets the counter to count
  upwards for the clocksource, removing the need for the
  clocksource core to invert the value.

- The Faraday driver also handles sched_clock()

On the Aspeed, the counter can only count downwards, so support
the timers in downward-counting mode as well, and flag the
Aspeed to use this mode. This mode was tested on the Gemini so
I have high hopes that it'll work fine on the Aspeed as well.

After this we have one driver for all three SoCs and a generic
Faraday FTTMR010 timer driver, which is nice.

Cc: Joel Stanley <joel@jms.id.au>
Cc: Jonas Jensen <jonas.jensen@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NJoel Stanley <joel@jms.id.au>
Tested-by: NJoel Stanley <joel@jms.id.au>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

This switches the clocksource to TIMER2 like the Moxart driver
does. Mainly to make it more similar to the Moxart/Aspeed driver
but also because it seems more neat to use the timers in order:
use timer 1, then timer 2.

Cc: Joel Stanley <joel@jms.id.au>
Tested-by: NJonas Jensen <jonas.jensen@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

This switches the drivers to use the bitops BIT() macro
to define bits.

Cc: Joel Stanley <joel@jms.id.au>
Tested-by: NJonas Jensen <jonas.jensen@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

This converts the Faraday FTTMR010 to use the state container
design pattern. Take some care to handle the state container
and free:ing of resources as has been done in the Moxa driver.

Cc: Joel Stanley <joel@jms.id.au>
Tested-by: NJonas Jensen <jonas.jensen@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

The Gemini now has a proper clock driver and a proper PCLK
assigned in its device tree. Drop the Gemini-specific hacks
to look up the system speed and rely on the clock framework
like everyone else.

Cc: Joel Stanley <joel@jms.id.au>
Tested-by: NJonas Jensen <jonas.jensen@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

We need to also prepare and enable the clock we are using to get
the right reference count and avoid it being shut off.
Tested-by: NJonas Jensen <jonas.jensen@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

arch_timer_mem_find_best_frame() looks through ARCH_TIMER_MEM_MAX_FRAMES
frames even after finding matches to ensure the best frame is chosen,
which means the variable frame will point to the last valid frame but
not necessarily the best frame.

On Juno, we get the following error as the wrong frame is returned as the
best frame from arch_timer_mem_find_best_frame():

  arch_timer: Unable to map frame @ 0x0000000000000000
  arch_timer: Frame missing phys irq.
  Failed to initialize '/timer@2a810000': -22

Fix the issue by correctly returning the best frame from
arch_timer_mem_find_best_frame().

Fixes: c389d701 ("clocksource: arm_arch_timer: split MMIO timer probing.")
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
Acked-by: NMark Rutland <mark.rutland@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: linux-arm-kernel@lists.infradead.org
Link: http://lkml.kernel.org/r/1494246747-17267-1-git-send-email-sudeep.holla@arm.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

In some rare randconfig builds, we end up with two functions being entirely
unused:

drivers/clocksource/arm_arch_timer.c:342:12: error: 'erratum_set_next_event_tval_phys' defined but not used [-Werror=unused-function]
 static int erratum_set_next_event_tval_phys(unsigned long evt,
drivers/clocksource/arm_arch_timer.c:335:12: error: 'erratum_set_next_event_tval_virt' defined but not used [-Werror=unused-function]
 static int erratum_set_next_event_tval_virt(unsigned long evt,

We could add an #ifdef around them, but we would already have to check for
several symbols there and there is a chance this would get more complicated
over time, so marking them as __maybe_unused is the simplest way to avoid the
harmless warnings.

Fixes: 01d3e3ff ("arm64: arch_timer: Rework the set_next_event workarounds")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
Acked-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Christoffer Dall <christoffer.dall@linaro.org>
Link: http://lkml.kernel.org/r/20170419173737.3846098-1-arnd@arndb.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

Malta was the only platform probing this driver from platform code
without using device tree. With that code removed, gic_clocksource_init
is redundant so remove it.
Signed-off-by: NMatt Redfearn <matt.redfearn@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Link: http://lkml.kernel.org/r/1492604806-23420-2-git-send-email-matt.redfearn@imgtec.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/clocksource/.

[Note: With regard to cs5535-clockevt.c, Thomas Gleixner asked whether the
 timer_irq parameter is required for the driver to work on anything other than
 arbitrary hardware which has it mapped to 0.  Jens Rottmann replied that the
 parameter defaults to 0, which means:

	1. autodetect (=keep IRQ BIOS has set up)
	2. if that fails use CONFIG_CS5535_MFGPT_DEFAULT_IRQ
	   (see drivers/misc/cs5535-mfgpt.c: cs5535_mfgpt_set_irq())

 Jens further noted that there may not be any systems that have CS5535/36
 devices that support EFI and secure boot.]
Suggested-by: NAlan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: NDavid Howells <dhowells@redhat.com>
cc: Daniel Lezcano <daniel.lezcano@linaro.org>
cc: Thomas Gleixner <tglx@linutronix.de>
cc: Jens Rottmann <Jens.Rottmann@ADLINKtech.com>
cc: linux-kernel@vger.kernel.org

The patch add memory-mapped timer register support by using the
information provided by the new GTDT driver of ACPI.
Signed-off-by: NFu Wei <fu.wei@linaro.org>
Reviewed-by: NHanjun Guo <hanjun.guo@linaro.org>
[Mark: verify CNTFRQ, only register the first frame]
Signed-off-by: NMark Rutland <mark.rutland@arm.com>

The patch update arm_arch_timer driver to use the function
provided by the new GTDT driver of ACPI.
By this way, arm_arch_timer.c can be simplified, and separate
all the ACPI GTDT knowledge from this timer driver.
Signed-off-by: NFu Wei <fu.wei@linaro.org>
Signed-off-by: NHanjun Guo <hanjun.guo@linaro.org>
Tested-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Reviewed-by: NHanjun Guo <hanjun.guo@linaro.org>
Tested-by: NHanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: NMark Rutland <mark.rutland@arm.com>

Currently the code to probe MMIO architected timers mixes DT parsing with
actual poking of hardware. This makes the code harder than necessary to
understand, and makes it difficult to add support for probing via ACPI.

This patch splits the DT parsing from HW probing. The DT parsing now
lives in arch_timer_mem_of_init(), which fills in an arch_timer_mem
structure that it hands to probing functions that can be reused for ACPI
support.

Since the rate detection logic will be slight different when using ACPI,
the probing is performed as a number of steps. This results in more code
for the moment, and some arguably redundant work, but simplifies matters
considerably when ACPI support is added.
Signed-off-by: NFu Wei <fu.wei@linaro.org>
[Mark: refactor the probing split]
Signed-off-by: NMark Rutland <mark.rutland@arm.com>

To cleanly split code paths specific to ACPI or DT at a higher level,
this patch removes arch_timer_init(), folding the relevant
parts of its logic into existing callers.

This pathes the way for further rework, and saves a few lines.
Signed-off-by: NFu Wei <fu.wei@linaro.org>
Reviewed-by: NHanjun Guo <hanjun.guo@linaro.org>
[Mark: reword commit message]
Signed-off-by: NMark Rutland <mark.rutland@arm.com>

When booting with DT, it's possible for timer nodes to be probed in any
order. Some common initialisation needs to occur after all nodes have
been probed, and arch_timer_common_init() has code to detect when this
has happened.

This logic is DT-specific, and it would be best to factor it out of the
common code that will be shared with ACPI.

This patch folds this into the existing arch_timer_needs_probing(),
which is renamed to arch_timer_needs_of_probing(), and no longer takes
any arguments. This is only called when using DT, and not when using
ACPI, which will have a deterministic probe order.
Signed-off-by: NFu Wei <fu.wei@linaro.org>
Reviewed-by: NHanjun Guo <hanjun.guo@linaro.org>
[Mark: reword commit message]
Signed-off-by: NMark Rutland <mark.rutland@arm.com>

For historical reasons, rate detection when probing via DT is somewhat
convoluted. We tried to package this up in arch_timer_detect_rate(), but
with the addition of ACPI worse, and gets in the way of stringent rate
checking when ACPI is used.

This patch makes arch_timer_detect_rate() specific to DT, ripping out
ACPI logic. In preparation for rework of the MMIO timer probing, the
reading of the relevant CNTFRQ register is factored out to callers. The
function is then renamed to arch_timer_of_configure_rate(), which better
represents its new place in the world.

Comments are added in the DT and ACPI probe paths to explain this.
Signed-off-by: NFu Wei <fu.wei@linaro.org>
[Mark: reword commit message]
Signed-off-by: NMark Rutland <mark.rutland@arm.com>

In preparation for making the clockevents core NTP correction aware,
all clockevent device drivers must set ->min_delta_ticks and
->max_delta_ticks rather than ->min_delta_ns and ->max_delta_ns: a
clockevent device's rate is going to change dynamically and thus, the
ratio of ns to ticks ceases to stay invariant.

Make the timer-atlas7 clockevent driver initialize these fields properly.

This patch alone doesn't introduce any change in functionality as the
clockevents core still looks exclusively at the (untouched) ->min_delta_ns
and ->max_delta_ns. As soon as this has changed, a followup patch will
purge the initialization of ->min_delta_ns and ->max_delta_ns from this
driver.

Cc: Ingo Molnar <mingo@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: Barry Song <baohua@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Acked-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: NNicolai Stange <nicstange@gmail.com>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>

In preparation for making the clockevents core NTP correction aware,
all clockevent device drivers must set ->min_delta_ticks and
->max_delta_ticks rather than ->min_delta_ns and ->max_delta_ns: a
clockevent device's rate is going to change dynamically and thus, the
ratio of ns to ticks ceases to stay invariant.

Make the sh_cmt clockevent driver initialize these fields properly.

This patch alone doesn't introduce any change in functionality as the
clockevents core still looks exclusively at the (untouched) ->min_delta_ns
and ->max_delta_ns. As soon as this has changed, a followup patch will
purge the initialization of ->min_delta_ns and ->max_delta_ns from this
driver.

Cc: Ingo Molnar <mingo@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: NNicolai Stange <nicstange@gmail.com>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>

In preparation for making the clockevents core NTP correction aware,
all clockevent device drivers must set ->min_delta_ticks and
->max_delta_ticks rather than ->min_delta_ns and ->max_delta_ns: a
clockevent device's rate is going to change dynamically and thus, the
ratio of ns to ticks ceases to stay invariant.

Make the numachip clockevent driver initialize these fields properly.

This patch alone doesn't introduce any change in functionality as the
clockevents core still looks exclusively at the (untouched) ->min_delta_ns
and ->max_delta_ns. As soon as this has changed, a followup patch will
purge the initialization of ->min_delta_ns and ->max_delta_ns from this
driver.

Cc: Ingo Molnar <mingo@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: NNicolai Stange <nicstange@gmail.com>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>

In preparation for making the clockevents core NTP correction aware,
all clockevent device drivers must set ->min_delta_ticks and
->max_delta_ticks rather than ->min_delta_ns and ->max_delta_ns: a
clockevent device's rate is going to change dynamically and thus, the
ratio of ns to ticks ceases to stay invariant.

Make the metag_generic clockevent driver initialize these fields properly.

This patch alone doesn't introduce any change in functionality as the
clockevents core still looks exclusively at the (untouched) ->min_delta_ns
and ->max_delta_ns. As soon as this has changed, a followup patch will
purge the initialization of ->min_delta_ns and ->max_delta_ns from this
driver.

Cc: Ingo Molnar <mingo@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: James Hogan <james.hogan@imgtec.com>
Acked-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: NNicolai Stange <nicstange@gmail.com>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>

In preparation for making the clockevents core NTP correction aware,
all clockevent device drivers must set ->min_delta_ticks and
->max_delta_ticks rather than ->min_delta_ns and ->max_delta_ns: a
clockevent device's rate is going to change dynamically and thus, the
ratio of ns to ticks ceases to stay invariant.

Make the dw_apb clockevent driver initialize these fields properly.

This patch alone doesn't introduce any change in functionality as the
clockevents core still looks exclusively at the (untouched) ->min_delta_ns
and ->max_delta_ns. As soon as this has changed, a followup patch will
purge the initialization of ->min_delta_ns and ->max_delta_ns from this
driver.

Cc: Ingo Molnar <mingo@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: NNicolai Stange <nicstange@gmail.com>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>

Currently, the arch timer driver uses ARCH_TIMER_PHYS_SECURE_PPI to mean
the driver will use the secure PPI *and* potentially also use the
non-secure PPI. This is somewhat confusing.

For arm64 it never makes sense to use the secure PPI, but we do anyway,
inheriting this behaviour from 32-bit arm. For ACPI, we may not even
have a valid secure PPI, so we need to be able to only request the
non-secure PPI.

To that end, this patch reworks the timer driver so that we can request
the non-secure PPI alone. The PPI selection is split out into a new
function, arch_timer_select_ppi(), and verification of the selected PPI
is shifted out to callers (as DT may select the PPI by other means and
must handle this anyway).

We now consistently use arch_timer_has_nonsecure_ppi() to determine
whether we must manage a non-secure PPI *in addition* to a secure PPI.
When we only have a non-secure PPI, this returns false.
Signed-off-by: NFu Wei <fu.wei@linaro.org>
Tested-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
[Mark: reword commit message]
Signed-off-by: NMark Rutland <mark.rutland@arm.com>

This patch add a new enum "arch_timer_spi_nr" and use it in the driver.
Just for code's readability, no functional change.
Signed-off-by: NFu Wei <fu.wei@linaro.org>
Acked-by: NMark Rutland <mark.rutland@arm.com>
Signed-off-by: NMark Rutland <mark.rutland@arm.com>

To support the arm_arch_timer via ACPI we need to share defines and enums
between the driver and the ACPI parser code.
So we split out the relevant defines and enums into arm_arch_timer.h.

No functional change.
Signed-off-by: NFu Wei <fu.wei@linaro.org>
Acked-by: NMark Rutland <mark.rutland@arm.com>
Tested-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: NMark Rutland <mark.rutland@arm.com>

In preparation for moving the PPI enum out into a header, rename the
enum and its constituent values these so they are namespaced w.r.t. the
arch timer. This will aid consistency and avoid potential name clashes
when this move occurs.

No functional change.
Signed-off-by: NFu Wei <fu.wei@linaro.org>
Tested-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
[Mark: reword commit message]
Signed-off-by: NMark Rutland <mark.rutland@arm.com>

In preparation for moving the type macros out into a header, rename
these so they are namespaced w.r.t. the arch timer. We'll apply the same
prefix to other definitions in subsequent patches. This will aid
consistency and avoid potential name clahses when this move occurs.

No functional change.
Signed-off-by: NFu Wei <fu.wei@linaro.org>
Tested-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
[Mark: reword commit message]
Signed-off-by: NMark Rutland <mark.rutland@arm.com>

Almost all string in the arm_arch_timer driver duplicate an common
prefix (though a few do not). For consistency, it would be better to use
pr_fmt(), and always use this prefix. At the same time, we may as well
clean up some whitespace issues in arch_timer_banner and
arch_timer_init.

No functional change.
Signed-off-by: NFu Wei <fu.wei@linaro.org>
Acked-by: NMark Rutland <mark.rutland@arm.com>
Tested-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
[Mark: reword commit message]
Signed-off-by: NMark Rutland <mark.rutland@arm.com>

The plain Faraday FTTMR010 timer needs a clock to figure out its
tick rate, and the gemini reads it directly from the system
controller set-up. Split the init function and add two paths for
the two compatible-strings. We only support clocking using PCLK
because of lack of documentation on how EXTCLK works.

The Gemini still works like before, but we can also support a
generic, clock-based version.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

After some research it turns out that the "Gemini" timer is
actually a generic IP block from Faraday Technology named
FTTMR010, so as to not make things too confusing we need to
rename the driver and its symbols to make sense.

The implementation remains the same in this patch but we fix
the copy-paste error in the timer name "nomadik_mtu" as we're
at it.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

The clock supplying the arm-global-timer on the rk3188 is coming from the
the cpu clock itself and thus changes its rate everytime cpufreq adjusts
the cpu frequency making this timer unsuitable as a stable clocksource
and sched clock.

The rk3188, rk3288 and following socs share a separate timer block already
handled by the rockchip-timer driver. Therefore adapt this driver to also
be able to act as clocksource and sched clock on rk3188.

In order to test clocksource you can run following commands and check
how much time it take in real. On rk3188 it take about ~45 seconds.

    cpufreq-set -f 1.6GHZ
    date; sleep 60; date

In order to use the patch you need to declare two timers in the dts
file. The first timer will be initialized as clockevent provider
and the second one as clocksource. The clockevent must be from
alive subsystem as it used as backup for the local timers at sleep
time.

The patch does not break compatibility with older device tree files.
The older device tree files contain only one timer. The timer
will be initialized as clockevent, as expected.

rk3288 (and probably anything newer) is irrelevant to this patch,
as it has the arch timer interface. This patch may be useful
for Cortex-A9/A5 based parts.
Signed-off-by: NAlexander Kochetkov <al.kochet@gmail.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

Printing with pr_* functions requires adding line break manually.
Signed-off-by: NRafał Miłecki <rafal@milecki.pl>
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

Add an implementation for the ARM delay timer, which is used for
udelay().  This provides less CPU dependent and more accurate delays -
the CPU loop on Marvell Dove appears to calibrate to around 6% too
short.
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

Rather than reading the clock rate three times, read it once - we are
about to add a fourth usage.
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

In order to deal with ACPI enabled platforms suffering from the
HISILICON_ERRATUM_161010101, let's add the required OEM data that
allow the workaround to be enabled.
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: Ndann frazier <dann.frazier@canonical.com>
Tested-by: NHanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: NHanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

Just as we're able to identify a broken platform using some DT
information, let's enable a way to spot the offenders with ACPI.

The difference is that we can only match on some OEM info instead
of implementation-specific properties. So in order to avoid the
insane multiplication of errata structures, we allow an array
of OEM descriptions to be attached to an erratum structure.
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: Ndann frazier <dann.frazier@canonical.com>
Tested-by: NHanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: NHanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

Cortex-A73 (all versions) counter read can return a wrong value
when the counter crosses a 32bit boundary.

The workaround involves performing the read twice, and to return
one or the other depending on whether a transition has taken place.
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>