The commit 55ee7017 ("arm: omap2: board-generic: use
omap4_local_timer_init for AM437x") unintentionally changes the
clocksource devices for AM437x from OMAP GP Timer to SyncTimer32K.

Unfortunately, the SyncTimer32K is starving from frequency deviation
as mentioned in commit 5b5c0135 ("ARM: OMAP2+: AM43x: Use gptimer
as clocksource") and, as reported by Franklin [1], even its monotonic
nature is under question (most probably there is a HW issue, but it's
still under investigation).

Taking into account above facts It's reasonable to rollback to the use
of omap3_gptimer_timer_init().

[1] http://www.spinics.net/lists/linux-omap/msg127425.html

Fixes: 55ee7017 ("arm: omap2: board-generic: use
omap4_local_timer_init for AM437x")
Reported-by: NCooper Jr., Franklin <fcooper@ti.com>
Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

There is no point in having an extra type for extra confusion. u64 is
unambiguous.

Conversion was done with the following coccinelle script:

@rem@
@@
-typedef u64 cycle_t;

@fix@
typedef cycle_t;
@@
-cycle_t
+u64
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: John Stultz <john.stultz@linaro.org>

With the introduction of hwmod module clocks, the name of the hwmod
main clk may not be available before hwmod setup, as hwmod setup
may lookup the main clock dynamically based on the hwmod name.
Thus, change the order of hwmod setup and main clock handling for
the timer code, to make sure the main clock is going to be
available.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

A few platforms are currently missing clocksource_probe() completely
in their time_init functionality. On OMAP3430 for example, this is
causing cpuidle to be pretty much dead, as the counter32k is not
going to be registered and instead a gptimer is used as a clocksource.
This will tick in periodic mode, preventing any deeper idle states.

While here, also drop one unnecessary check for populated DT before
existing clocksource_probe() call.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

System will misbehave in the following case:
- AM43XX only build (UP);
- CONFIG_CPU_IDLE=y
- ARM TWD timer enabled and selected as clockevent device.

In the above case, It's expected that broadcast timer will be used as
backup timer when CPUIdle will put MPU in low power states where ARM
TWD will stop and lose its context. But, the CONFIG_SMP might not be
selected when kernel is built for AM43XX SoC only and, as result,
GENERIC_CLOCKEVENTS_BROADCAST option will not be selected also. This
will break CPUIdle and System will stuck in low power states.

Hence, fix it by selecting GENERIC_CLOCKEVENTS_BROADCAST option for
AM43XX SoCs always and add empty tick_broadcast() function
implementation - no need to send any IPI on UP. After this change
timer1 will be selected as broadcast timer the same way as for SMP,
and CPUIdle will work properly.
Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Timer 12 on DRA7 SoCs is reserved for secure usage on high-secure (HS)
devices. The timer cannot be used by the kernel on HS devices, but is
available on regular general purpose (GP) devices. This is similar to the
behavior on OMAP3 devices, so extend the logic used in commit ad24bde8
("ARM: OMAP3: Dynamically disable secure timer nodes for secure devices")
to remove the secure timer on DRA7xx SoCs at run-time based on the SoC
device type.
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

now that we have a working 32k clocksource driver,
we can limit HWMOD usage to non-DT boots and rely
on clocksource_of_init() every time we boot
with DT.

While at that, also make sure that we don't disable
the 32-counter device so it gets probed by its driver.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

this function is not only about the 32k sync
timer, it's OMAP's generic init_time implementation.

Let's rename it to make that detail easier to
notice.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

If booting with DT, let's make sure to always
call clocksource_of_init() as this will make
it easier to move timer code to drivers/clocksource
in the future.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

no functional changes, just moving that function
closer to its calling location.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

instead of constantly defining a small wrapper
around __omap_sync32k_timer_init(), let's define
a generic one which can be used by all OMAPs.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

__omap_sync32k_timer_init(), now takes the clock
source as a parameter. This means we no longer need
__omap_gptimer_init().

Note that __omap_sync32k_timer_init() will be
renamed in a follow-up patch as it's not longer 32k
source specific.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

as it turns out, __omap_gptimer_init() and
__omap_sync32k_timer_init() are essentially
the same thing, but __omap_gptimer_init() wants
to always use gptimer.

Instead of forcing all those devices to pass
a use_gptimer cmdline argument, we add a new
function argument to __omap_sync32k_timer_init()
in preparation to deleting __omap_gptimer_init().

On a follow-up patch, we will remove uses of
__omap_gptimer_init() and replace them with
__omap_sync32k_timer_init() and pass the last
argument as true.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

those macros just make it a lot more difficult
to grep around and actually find similarities.

In this patch, we will simply remove them and
replace with actual functions and later commits
will come to further clean this up.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

omap4_local_timer_init() can be used by other
platforms as is. At least AM437x wants to use
it. Instead of making omap4-only and providing
a stub for builds without OMAP4, we can just
make sure that function is always available
for all SoCs that need it.
Reported-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Seeing the 'of' characters in a symbol that is being called from
ACPI seems to freak out people. So let's do a bit of pointless
renaming so that these folks do feel at home.
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Reviewed-by: NHanjun Guo <hanjun.guo@linaro.org>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NHanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

When bringing up a new SoC we needlessly prevent booting at timer
init if timer clock_set_parent fails. This can fail if the system
is booting on bootloader configured PLL values until the clock
framework driver for the PLL is implemented.

Let's just WARN instead, this will provide helpful information
for anybody bringing up a new SoC what needs to be fixed.

This allows to boot dm814x that's still missing the PLL driver.
Signed-off-by: NTony Lindgren <tony@atomide.com>

Migrate omap2 driver to the new 'set-state' interface provided by
clockevents core, the earlier 'set-mode' interface is marked obsolete
now.

This also enables us to implement callbacks for new states of clockevent
devices, for example: ONESHOT_STOPPED.
Acked-by: NSantosh Shilimkar <ssantosh@kernel.org>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>

Inspired by a patch from Felipe Balbi <balbi@ti.com>, we can
now get rid of most the code in omap4_local_timer_init.

Omap4 is now device tree only.. And we have not properly supported
omap4 ES1.0 revision for a really long time AFAIK.

Let's just remove all that code to simplify things. This assumes
we have arm,cortex-a9-twd-timer entry in the omap4.dtsi file, which
we do.
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The of_node_put() function tests whether its argument is NULL and then
returns immediately if so.  Furthermore, the kerneldoc for
of_node_put() explicitly supports passing in a NULL pointer as its
argument.  Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.
Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
[paul@pwsan.com: dropped the omap_device.c and omap_hwmod.c changes for
 now, edited the commit message accordingly and to note the documented
 "contract"]
Reviewed-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

With recent changes to use determine_rate, the comparison of two
clocks won't work without clk_is_match that does __clk_get_hw
on the clocks first.

As we've been unconditionally already calling clk_set_parent
already because of the bogus comparison, let's just remove the
check as suggested by Stephen Boyd <sboyd@codeaurora.org>.

Cc: Michael Turquette <mturquette@linaro.org>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tero Kristo <t-kristo@ti.com>
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Acked-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Fix dm814 and dm816 clocks and timer init.

Cc: Brian Hutchinson <b.hutchman@gmail.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Errata i856 for the AM572x (DRA7xx) points out that the 32.768KHz external
crystal is not enabled at power up.  Instead the CPU falls back to using
an emulation for the 32KHz clock which is SYSCLK1/610.  SYSCLK1 is usually
20MHz on boards so far (which gives an emulated frequency of 32.786KHz),
but can also be 19.2 or 27MHz which result in much larger drift.

Since this is used to drive the master counter at 32.768KHz * 375 /
2 = 6.144MHz, the emulated speed for 20MHz is of by 570ppm, or about 43
seconds per day, and more than the 500ppm NTP is able to tolerate.

Checking the CTRL_CORE_BOOTSTRAP register can determine if the CPU
is using the real 32.768KHz crystal or the emulated SYSCLK1/610, and
by known that the real counter frequency can be determined and used.
The real speed is then SYSCLK1 / 610 * 375 / 2 or SYSCLK1 * 75 / 244.
Signed-off-by: NLen Sorensen <lsorense@csclub.uwaterloo.ca>
Tested-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The switch statement of the possible list of SYSCLK1 frequencies is
missing a 0 in 4 out of the 7 frequencies.

Fixes: fa6d79d2 ("ARM: OMAP: Add initialisation for the real-time counter")
Cc: stable@vger.kernel.org # v3.7+
Signed-off-by: NLen Sorensen <lsorense@csclub.uwaterloo.ca>
Reviewed-by: NLokesh Vutla <lokeshvutla@ti.com>
Acked-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

of_device_ids (i.e. compatible strings and the respective data) are not
supposed to change at runtime. All functions working with of_device_ids
provided by <linux/of.h> work with const of_device_ids. So mark the
non-const function parameters and structs for OMAP2+ as const, too.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NTony Lindgren <tony@atomide.com>

All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
Need to use endian neutral functions to read/write h/w registers.
I.e instead of __raw_read[lw] and __raw_write[lw] functions code
need to use read[lw]_relaxed and write[lw]_relaxed functions.
If the first simply reads/writes register, the second will byteswap
it if host operates in BE mode.

Changes are trivial sed like replacement of __raw_xxx functions
with xxx_relaxed variant.
Signed-off-by: NVictor Kamensky <victor.kamensky@linaro.org>
Signed-off-by: NTaras Kondratiuk <taras.kondratiuk@linaro.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The variable use_gptimer_clksrc is only used by two __init functions,
So we can freely free it after boot.
Signed-off-by: NOussama Ghorbel <ghorbel@pivasoftware.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The SyncTimer in AM43x is clocked using the following two sources:
1) An inaccuarte 32k clock (CLK_32KHZ) derived from PER DPLL, causing system
   time to go slowly (~10% deviation).
2) external 32KHz RTC clock, which may not always be available on board like
   in the case of ePOS EVM

Use gptimer as clocksource instead, as is done in the case of AM335x
(which does not have a SyncTimer). With this, system time keeping works
accurately.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

clk_init is now separated to a common function which gets called for all
SoC:s, which initializes the DT clocks and calls the SoC specific clock init.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

The 32 bit sched_clock interface now supports 64 bits. Upgrade to
the 64 bit function to allow us to remove the 32 bit registration
interface.

Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Acked-by: Santosh Shilimkar<santosh.shilimkar@ti.com>
Signed-off-by: NKevin Hilman <khilman@linaro.org>

Otherwise we can get an error with some configs:

arch/arm/mach-omap2/timer.c:73: undefined reference to `omap_smc1'
Signed-off-by: NTony Lindgren <tony@atomide.com>

The realtime counter called master counter, produces the count
used by the private timer peripherals in the MPU_CLUSTER. The
CNTFRQ per cpu register is used to denote the frequency of the counter.
Currently the frequency value is passed from the
DT file, but this is not scalable when we have other non-DT guest
OS. This register must be set to the right value by the
secure rom code. Setting this register helps in propagating the right
frequency value across OSes.

More discussions and the reason for adding this in a non-DT
way can be seen from below.
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg93832.html

So configuring this secure register for all the cpus here.

Cc: Nishanth Menon <nm@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Tested-by: NNishanth Menon <nm@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NSricharan R <r.sricharan@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The real time counter also called master counter, is a free-running
counter. It produces the count used by the CPU local timer peripherals
in the MPU cluster. The timer counts at a rate of 6.144 MHz.

The ratio registers are missing for a sys-clk of 20MHZ which is used
by DRA7 socs. So because of this, the counter was getting wrongly
programmed for a sys-clk of 38.4Mhz(default). So adding the ratio
registers for 20MHZ sys-clk.
Tested-by: NNishanth Menon <nm@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NSricharan R <r.sricharan@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Since dra7 reuses the  function 'omap5_realtime_timer_init' in
arch/arm/mach-omap2/board-generic.c as timer init function, it has to be
built for this SoC as well.
Signed-off-by: NSimon Barth <Simon.Pe.Barth@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch proposes to remove the IRQF_DISABLED flag from OMAP code
It's a NOOP since 2.6.35, and will be removed one day.
Signed-off-by: NMichael Opdenacker <michael.opdenacker@free-electrons.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The denominator should be load from INCREMENTOR_DENUMERATOR_RELOAD_OFFSET
rather than INCREMENTER_NUMERATOR_OFFSET.

This is more likely a typo, since INCREMENTER_DENUMERATOR_RELOAD[23:17] is
reserved. It seems that it won't make much trouble without this fix, because
the useful [11:0] bits are mask and set the right value. Anyway, reading
from a right address is better choice.
Signed-off-by: NChen Baozi <baozich@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

All of OMAP5 timer support for clocksource and clockevent is completely
reused across DRA7.
Signed-off-by: NR Sricharan <r.sricharan@ti.com>
Signed-off-by: NRajendra Nayak <rnayak@ti.com>

A recent patch ef3160cd (ARM: OMAP2+: Divorce from local timer API,
2013-03-04) broke the omap build when SMP=n because the TWD functions
are only compiled on SMP=y builds. Stub out the TWD calls when the TWD
isn't built in to to keep everything building.

arch/arm/mach-omap2/built-in.o: In function `omap4_local_timer_init':
dss-common.c:(.init.text+0x1d90): undefined reference to `twd_local_timer_register'
Reported-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NOlof Johansson <olof@lixom.net>

of_property_read_string_index(...,&oh_name) in omap_dm_timer_init_one
does not alter the value of 'oh_name' even if the relevant function
fails and as 'oh_name' in stack may have a non-zero value, it would
be misunderstood by timer code that DT has specified "ti,hwmod"
property for timer. 'oh_name' in this scenario would be a junk value,
this would result in module not being enabled by hwmod API's for
timer, and in turn crash.
Signed-off-by: NAfzal Mohammed <afzal@ti.com>
Acked-by: NJon Hunter <jgchunter@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Now that the TWD doesn't rely on the local timer API, OMAP can
stop selecting it in Kconfig and relying on the config option to
decide if it should call smp_twd functions.
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>