For the sake of consistency, let's rename the file to a name similar
to other file names in this directory.
Signed-off-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

Allow building the PIT driver when COMPILE_TEST is enabled. Also remove its
default value so it can be disabled.
Signed-off-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

Move the ATMEL_TCB_CLKSRC option to drivers/clocksource and make it silent
if COMPILE_TEST is not selected.

Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

Now that the driver is registered early enough, use the TCB as the
sched_clock which is much more accurate than the jiffies implementation.
Signed-off-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

atmel_tclib is probed too late in the boot process to be able to use the
TCB as the boot clocksource. This is an issue for SoCs without the PIT
(sams70, samv70 and samv71 families) as they simply currently can't boot.

Get rid of the atmel_tclib dependency and probe everything on our own using
the correct device tree binding.

This also allows getting rid of ATMEL_TCB_CLKSRC_BLOCK and makes the driver
a bit more flexible as the TCB is not hardcoded in the kernel anymore.
Signed-off-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

Move linux/atmel_tc.h to the SoC specific folder include/soc/at91.
Signed-off-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: NThierry Reding <thierry.reding@gmail.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

Aggregate common register accesses into shared functions for
maintainability.
Signed-off-by: NSugaya Taichi <sugaya.taichi@socionext.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

Add a shutdown operation to support shutdown timer.
Signed-off-by: NSugaya Taichi <sugaya.taichi@socionext.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

Fix mlb_set_oneshot_state() to enable one-shot timer.
The function should stop and start a timer, but "start" statement was
dropped. Kick the register to start one-shot timer.

Fixes: b58f28f3 ("clocksource/drivers/timer-milbeaut: Introduce timer for Milbeaut SoCs")
Signed-off-by: NSugaya Taichi <sugaya.taichi@socionext.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

Since the clocksource framework has the support for suspend time
compensation. Re-work the driver to use that, so we can reduce the
duplicate code.
Suggested-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: NJoseph Lo <josephl@nvidia.com>
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

This is only used on arm and arm64 platforms. Add COMPILE_TEST option.

Tested with 5.1-rc3+ on Fedora/RISCV. CONFIG_ARM_TIMER_SP804 no more shows
up in riscv config.
Signed-off-by: NDavid Abdurachmanov <david.abdurachmanov@gmail.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

The suniv (new F-series) chip has a timer with less functionality than
the A10 timer, e.g. it has only 3 channels.

Add a new compatible for it. As we didn't use the extra channels on A10
either now, the code needn't to be changed.

The suniv chip is based on ARM926EJ-S CPU, thus it has no architecture timer.

Register sun4i_timer as sched_clock on it.
Signed-off-by: NMesih Kilinc <mesihkilinc@gmail.com>
Acked-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Acked-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

Add timer driver for Milbeaut SoCs series.

The timer has two 32-bit width down counters, one of which is configured
as a clockevent device and the other is configured as a clock source.
Signed-off-by: NSugaya Taichi <sugaya.taichi@socionext.com>
Acked-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Add support for the Tegra210 timer that runs at oscillator clock
(TMR10-TMR13). We need these timers to work as clock event device and to
replace the ARMv8 architected timer due to it can't survive across the
power cycle of the CPU core or CPUPORESET signal. So it can't be a wake-up
source when CPU suspends in power down state.

Also convert the original driver to use timer-of API.

Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NJoseph Lo <josephl@nvidia.com>
Acked-by: NThierry Reding <treding@nvidia.com>
Acked-by: NJon Hunter <jonathanh@nvidia.com>
Acked-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

For the sake of consistency, let's rename the file to a name similar
to other file names in this directory.
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

For the sake of consistency, let's rename the file to a name similar
to other file names in this directory.
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

For the sake of consistency, let's rename the file to a name similar
to other file names in this directory.
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

The driver does not use sched.h and platform_device.h.
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

While freeing interrupt handlers in error path, don't assume that all
requested interrupts are per-processor interrupts and properly release
standard interrupts too.
Reported-by: NKrzysztof Kozlowski <krzk@kernel.org>
Fixes: 56a94f13 ("clocksource: exynos_mct: Avoid blocking calls in the cpu hotplug notifier")
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: NKrzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: NChanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

Exynos Multi-Core Timer driver is used only on device-tree based
systems, so remove non-dt related code. In case of !CONFIG_OF
the code is anyway equal because of_irq_count() has a stub
returning 0. Device node pointer is always provided when driver
has been probed from device tree.
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: NKrzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: NChanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

Currently, clocksource registration happens for an invalid cpu for
non-smp kernels. This lead to kernel panic as cpu hotplug registration
will fail for those cpus. Moreover, riscv_hartid_to_cpuid can return
errors now.

Do not proceed if hartid or cpuid is invalid. Take this opportunity to
print appropriate error strings for different failure cases.
Signed-off-by: NAtish Patra <atish.patra@wdc.com>
Reviewed-by: NAnup Patel <anup@brainfault.org>
Reviewed-by: NPalmer Dabbelt <palmer@sifive.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

When shutting down the timer, ensure that after we have stopped the
timer any pending interrupts are cleared. This fixes a problem when
suspending, as interrupts are disabled before the timer is stopped,
so the timer interrupt may still be asserted, preventing the system
entering a low power state when the wfi is executed.
Signed-off-by: NStuart Menefy <stuart.menefy@mathembedded.com>
Reviewed-by: NKrzysztof Kozlowski <krzk@kernel.org>
Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Cc: <stable@vger.kernel.org> # v4.3+
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

When a timer tick occurs and the clock is in one-shot mode, the timer
needs to be stopped to prevent it triggering subsequent interrupts.
Currently this code is in exynos4_mct_tick_clear(), but as it is
only needed when an ISR occurs move it into exynos4_mct_tick_isr(),
leaving exynos4_mct_tick_clear() just doing what its name suggests it
should.
Signed-off-by: NStuart Menefy <stuart.menefy@mathembedded.com>
Reviewed-by: NKrzysztof Kozlowski <krzk@kernel.org>
Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Cc: stable@vger.kernel.org # v4.3+
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

The Allwinner A64 SoC is known[1] to have an unstable architectural
timer, which manifests itself most obviously in the time jumping forward
a multiple of 95 years[2][3]. This coincides with 2^56 cycles at a
timer frequency of 24 MHz, implying that the time went slightly backward
(and this was interpreted by the kernel as it jumping forward and
wrapping around past the epoch).

Investigation revealed instability in the low bits of CNTVCT at the
point a high bit rolls over. This leads to power-of-two cycle forward
and backward jumps. (Testing shows that forward jumps are about twice as
likely as backward jumps.) Since the counter value returns to normal
after an indeterminate read, each "jump" really consists of both a
forward and backward jump from the software perspective.

Unless the kernel is trapping CNTVCT reads, a userspace program is able
to read the register in a loop faster than it changes. A test program
running on all 4 CPU cores that reported jumps larger than 100 ms was
run for 13.6 hours and reported the following:

 Count | Event
-------+---------------------------
  9940 | jumped backward      699ms
   268 | jumped backward     1398ms
     1 | jumped backward     2097ms
 16020 | jumped forward       175ms
  6443 | jumped forward       699ms
  2976 | jumped forward      1398ms
     9 | jumped forward    356516ms
     9 | jumped forward    357215ms
     4 | jumped forward    714430ms
     1 | jumped forward   3578440ms

This works out to a jump larger than 100 ms about every 5.5 seconds on
each CPU core.

The largest jump (almost an hour!) was the following sequence of reads:
    0x0000007fffffffff → 0x00000093feffffff → 0x0000008000000000

Note that the middle bits don't necessarily all read as all zeroes or
all ones during the anomalous behavior; however the low 10 bits checked
by the function in this patch have never been observed with any other
value.

Also note that smaller jumps are much more common, with backward jumps
of 2048 (2^11) cycles observed over 400 times per second on each core.
(Of course, this is partially explained by lower bits rolling over more
frequently.) Any one of these could have caused the 95 year time skip.

Similar anomalies were observed while reading CNTPCT (after patching the
kernel to allow reads from userspace). However, the CNTPCT jumps are
much less frequent, and only small jumps were observed. The same program
as before (except now reading CNTPCT) observed after 72 hours:

 Count | Event
-------+---------------------------
    17 | jumped backward      699ms
    52 | jumped forward       175ms
  2831 | jumped forward       699ms
     5 | jumped forward      1398ms

Further investigation showed that the instability in CNTPCT/CNTVCT also
affected the respective timer's TVAL register. The following values were
observed immediately after writing CNVT_TVAL to 0x10000000:

 CNTVCT             | CNTV_TVAL  | CNTV_CVAL          | CNTV_TVAL Error
--------------------+------------+--------------------+-----------------
 0x000000d4a2d8bfff | 0x10003fff | 0x000000d4b2d8bfff | +0x00004000
 0x000000d4a2d94000 | 0x0fffffff | 0x000000d4b2d97fff | -0x00004000
 0x000000d4a2d97fff | 0x10003fff | 0x000000d4b2d97fff | +0x00004000
 0x000000d4a2d9c000 | 0x0fffffff | 0x000000d4b2d9ffff | -0x00004000

The pattern of errors in CNTV_TVAL seemed to depend on exactly which
value was written to it. For example, after writing 0x10101010:

 CNTVCT             | CNTV_TVAL  | CNTV_CVAL          | CNTV_TVAL Error
--------------------+------------+--------------------+-----------------
 0x000001ac3effffff | 0x1110100f | 0x000001ac4f10100f | +0x1000000
 0x000001ac40000000 | 0x1010100f | 0x000001ac5110100f | -0x1000000
 0x000001ac58ffffff | 0x1110100f | 0x000001ac6910100f | +0x1000000
 0x000001ac66000000 | 0x1010100f | 0x000001ac7710100f | -0x1000000
 0x000001ac6affffff | 0x1110100f | 0x000001ac7b10100f | +0x1000000
 0x000001ac6e000000 | 0x1010100f | 0x000001ac7f10100f | -0x1000000

I was also twice able to reproduce the issue covered by Allwinner's
workaround[4], that writing to TVAL sometimes fails, and both CVAL and
TVAL are left with entirely bogus values. One was the following values:

 CNTVCT             | CNTV_TVAL  | CNTV_CVAL
--------------------+------------+--------------------------------------
 0x000000d4a2d6014c | 0x8fbd5721 | 0x000000d132935fff (615s in the past)
Reviewed-by: NMarc Zyngier <marc.zyngier@arm.com>

========================================================================

Because the CPU can read the CNTPCT/CNTVCT registers faster than they
change, performing two reads of the register and comparing the high bits
(like other workarounds) is not a workable solution. And because the
timer can jump both forward and backward, no pair of reads can
distinguish a good value from a bad one. The only way to guarantee a
good value from consecutive reads would be to read _three_ times, and
take the middle value only if the three values are 1) each unique and
2) increasing. This takes at minimum 3 counter cycles (125 ns), or more
if an anomaly is detected.

However, since there is a distinct pattern to the bad values, we can
optimize the common case (1022/1024 of the time) to a single read by
simply ignoring values that match the error pattern. This still takes no
more than 3 cycles in the worst case, and requires much less code. As an
additional safety check, we still limit the loop iteration to the number
of max-frequency (1.2 GHz) CPU cycles in three 24 MHz counter periods.

For the TVAL registers, the simple solution is to not use them. Instead,
read or write the CVAL and calculate the TVAL value in software.

Although the manufacturer is aware of at least part of the erratum[4],
there is no official name for it. For now, use the kernel-internal name
"UNKNOWN1".

[1]: https://github.com/armbian/build/commit/a08cd6fe7ae9
[2]: https://forum.armbian.com/topic/3458-a64-datetime-clock-issue/
[3]: https://irclog.whitequark.org/linux-sunxi/2018-01-26
[4]: https://github.com/Allwinner-Homlet/H6-BSP4.9-linux/blob/master/drivers/clocksource/arm_arch_timer.c#L272Acked-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Tested-by: NAndre Przywara <andre.przywara@arm.com>
Signed-off-by: NSamuel Holland <samuel@sholland.org>
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

If the clock tree is not fully populated when the timer-sun5i init code
is called, attempts to get the clock rate for the timer would fail and
return 0.

Make the init code for both clock events and clocksource check the
returned clock rate and fail gracefully if the result is 0, instead of
causing a divide by 0 exception later on.

Fixes: 4a59058f ("clocksource/drivers/sun5i: Refactor the current code")
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Acked-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

A host running in VHE mode gets the EL2 physical timer as its time
source (accessed using the EL1 sysreg accessors, which get re-directed
to the EL2 sysregs by VHE).

The EL1 physical timer remains unused by the host kernel, allowing us to
pass that on directly to a KVM guest and saves us from emulating this
timer for the guest on VHE systems.

Store the EL1 Physical Timer's IRQ number in
struct arch_timer_kvm_info on VHE systems to allow KVM to use it.
Acked-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NChristoffer Dall <christoffer.dall@arm.com>

Commit 84badc5e ("ARM: dts: omap4: Move l4 child devices to probe
them with ti-sysc") started producing a warning for pwm-omap-dmtimer:

WARNING: CPU: 0 PID: 77 at drivers/bus/omap_l3_noc.c:147
l3_interrupt_handler+0x2f8/0x388
44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4PER2 (Idle):
Data Access in Supervisor mode during Functional access
...
__pm_runtime_idle
omap_dm_timer_disable
pwm_omap_dmtimer_start
pwm_omap_dmtimer_enable
pwm_apply_state
pwm_vibrator_start
pwm_vibrator_play_work

This is because the timer that pwm-omap-dmtimer is using is now being
probed with ti-sysc interconnect target module instead of omap_device
and the ti-sysc quirk for SYSC_QUIRK_LEGACY_IDLE is not fully
compatible with what omap_device has been doing.

We could fix this by reverting the timer changes and have the timer
probe again with omap_device. Or we could add more quirk handling to
ti-sysc driver. But as these options don't work nicely as longer term
solutions, let's just make timers probe with ti-sysc without any
quirks.

To do this, all we need to do is remove quirks for timers for ti-sysc,
and drop the bogus pm_runtime_irq_safe() flag for timer-ti-dm.

We should not use pm_runtime_irq_safe() anyways for drivers as it will
take a permanent use count on the parent device blocking the parent
devices from idling and has been forcing ti-sysc driver to use a
quirk flag.

Note that we will move the timer data to DEBUG section later on in
clean-up patches.

Fixes: 84badc5e ("ARM: dts: omap4: Move l4 child devices to probe them with ti-sysc")
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: H. Nikolaus Schaller <hns@goldelico.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Ladislav Michl <ladis@linux-mips.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Sebastian Reichel <sre@kernel.org>
Cc: Tero Kristo <t-kristo@ti.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Reported-by: NH. Nikolaus Schaller <hns@goldelico.com>
Tested-By: NAndreas Kemnade <andreas@kemnade.info>
Tested-By: NH. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commit 84badc5e ("ARM: dts: omap4: Move l4 child devices to probe
them with ti-sysc") moved some omap4 timers to probe with ti-sysc
interconnect target module. Turns out this broke pwm-omap-dmtimer
where we now try to reparent the clock to itself with the following:

omap_dm_timer_of_set_source: failed to set parent

With ti-sysc, we can now configure the clock sources in the dts
with assigned-clocks and assigned-clock-parents. So we should be able
to remove omap_dm_timer_of_set_source with clean-up patches later on.
But for now, let's just fix it first by checking if parent and fck
are the same and bail out of so.

Fixes: 84badc5e ("ARM: dts: omap4: Move l4 child devices to probe them with ti-sysc")
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: H. Nikolaus Schaller <hns@goldelico.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Ladislav Michl <ladis@linux-mips.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Sebastian Reichel <sre@kernel.org>
Cc: Tero Kristo <t-kristo@ti.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Reported-by: NH. Nikolaus Schaller <hns@goldelico.com>
Tested-By: NAndreas Kemnade <andreas@kemnade.info>
Tested-By: NH. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

We must add notrace on sched_clock_read, because it's called
by ftrace_graph_caller.
Signed-off-by: NGuo Ren <ren_guo@c-sky.com>

Timer startup must after timer_irq_enable. For qemu, timer tick
irq hanppens but irq not enable, so it will cause qemu boot failed.
Signed-off-by: NGuo Ren <ren_guo@c-sky.com>
Tested-by: NLiu Zhiwei <zhiwei_liu@c-sky.com>

Add clock driver for RDA Micro RDA8810PL SoC supporting OSTIMER
and HWTIMER.

RDA8810PL has two independent timers: OSTIMER (56 bit) and HWTIMER
(64 bit). Each timer provides optional interrupt support. In this
driver, OSTIMER is used for clockevents and HWTIMER is used for
clocksource.
Signed-off-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NManivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

In order to unify the names in this directory, let's rename the driver to be
prefixed with timer-*
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

In order to unify the names in this directory, let's rename the driver to be
prefixed with timer-*
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

In order to unify the names in this directory, let's rename the driver to be
prefixed with timer-*
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

In order to unify the names in this directory, let's rename the driver to be
prefixed with timer-*
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

In order to unify the names in this directory, let's rename the driver to be
prefixed with timer-*
Reviewed-by: NPalmer Dabbelt <palmer@sifive.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

Currently, we don't have a sched_clock registered for RISC-V systems.
This means Linux time keeping will use jiffies (running at HZ) as the
default sched_clock.

To avoid this, we explicity provide sched_clock using RISC-V rdtime
instruction (similar to riscv_timer clocksource).
Signed-off-by: NAnup Patel <anup@brainfault.org>
Reviewed-by: NPalmer Dabbelt <palmer@sifive.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

i.MX TPM needs "ipg" clock for register access and "per" clock for
timer function, the driver gets "ipg" clock by searching the clock
name, but timer-of initialization will get first clock in device
tree TPM node since no clock name specified in of_clk, that means
the "per" clock MUST be the first clock entry in device tree TPM
node, this patch specifies clock name for of_clk to avoid this
restriction, it makes TPM driver work properly with different sequence
of clock entries in device tree TPM node.
Signed-off-by: NAnson Huang <Anson.Huang@nxp.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

TIMER_INTR_MASK register (Base Address of Timer + 0x38) is not designed
for masking interrupts on ast2500 chips, and it's not even listed in
ast2400 datasheet, so it's not safe to access TIMER_INTR_MASK on aspeed
chips.

Similarly, TIMER_INTR_STATE register (Base Address of Timer + 0x34) is
not interrupt status register on ast2400 and ast2500 chips. Although
there is no side effect to reset the register in fttmr010_common_init(),
it's just misleading to do so.

Besides, "count_down" is renamed to "is_aspeed" in "fttmr010" structure,
and more comments are added so the code is more readble.
Signed-off-by: NTao Ren <taoren@fb.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

The function of_find_node_by_path() acquires a reference to the node
returned by it and that reference needs to be dropped by its caller.

integrator_ap_timer_init_of() doesn't do that.  The pri_node and the
sec_node are used as an identifier to compare against the current
node, so we can directly drop the refcount after getting the node from
the path as it is not used as pointer.

By dropping the refcount right after getting it, a single variable is
needed instead of two.

Fix this by use a single variable and drop the refcount right after
of_find_node_by_path().
Signed-off-by: NYangtao Li <tiny.windzz@gmail.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>