dm timer ops set_load() api allows to configure the load value and to
set the auto reload feature. But auto reload feature is independent of
load value and should be part of configuring pwm. This way pwm can be
disabled by disabling auto reload feature using set_pwm() so that the
current pwm cycle will be completed. Else pwm disabling causes the
cycle to be stopped abruptly.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20200305082715.15861-7-lokeshvutla@ti.com

omap_dm_timer_ops provide support to configure the pwm but there is no
support to get the current status. For configuring pwm it is advised to
check the current hw status instead of relying on pwm framework. So
implement a new timer ops to get the current status of pwm.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Acked-by: NTony Lindgen <tony@atomide.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20200305082715.15861-6-lokeshvutla@ti.com

Write to trigger register(OMAP_TIMER_TRIGGER_REG) will load the value
in Load register(OMAP_TIMER_LOAD_REG) into Counter register
(OMAP_TIMER_COUNTER_REG).

omap_dm_timer_set_load() writes into trigger register every time load
register is updated. When timer is configured in pwm mode, this causes
disruption in current pwm cycle, which is not expected especially when
pwm is used as PPS signal for synchronized PTP clocks. So do not write
into trigger register on updating the period.
Tested-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20200305082715.15861-5-lokeshvutla@ti.com

omap_dm_timer_enable() restores the entire context(including counter)
based on 2 conditions:
- If get_context_loss_count is populated and context is lost.
- If get_context_loss_count is not populated update unconditionally.

Case2 has a side effect of updating the counter register even though
context is not lost. When timer is configured in pwm mode, this is
causing undesired behaviour in the pwm period.

Instead of using get_context_loss_count call back, implement cpu_pm
notifier with context save and restore support. And delete the
get_context_loss_count callback all together.
Suggested-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
[tony@atomide.com: removed pm_runtime calls from cpuidle calls]
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20200316111453.15441-1-lokeshvutla@ti.com

Let's add runtime_suspend and resume functions and atomic enabled
flag. This way we can use these when converting to use cpuidle
for saving and restoring device context.

And we need to maintain the driver state in the driver as documented
in "9. Autosuspend, or automatically-delayed suspends" in the
Documentation/power/runtime_pm.rst document related to using driver
private lock and races with runtime_suspend().
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20200305082715.15861-3-lokeshvutla@ti.com

Use SPDX-License-Identifier instead of a verbose license text.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20200305082715.15861-2-lokeshvutla@ti.com

Generic clock rate needs to be set in case it was selected as timer clock
source in mchp_pit64b_init_mode(). Otherwise it will be enabled with wrong
rate.

Fixes: 625022a5 ("clocksource/drivers/timer-microchip-pit64b: Add Microchip PIT64B support")
Signed-off-by: NClaudiu Beznea <claudiu.beznea@microchip.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/1584352376-32585-1-git-send-email-claudiu.beznea@microchip.com

Recently all usages of setup_irq() was replaced by request_irq().
request_irq() does a few sanity checks that were not done in
setup_irq(), if they fail irq registration will fail. One of the check
is to ensure that non-NULL dev_id is passed in the case of shared irq.

Fix it by passing non-NULL dev_id while registering the shared irq.

Fixes: cc2550b4 ("clocksource: Replace setup_irq() by request_irq()")
Signed-off-by: Nafzal mohammed <afzal.mohd.ma@gmail.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20200312064817.19000-1-afzal.mohd.ma@gmail.com

request_irq() is preferred over setup_irq(). The early boot setup_irq()
invocations happen either via 'init_IRQ()' or 'time_init()', while
memory allocators are ready by 'mm_init()'.

Per tglx[1], setup_irq() existed in olden days when allocators were not
ready by the time early interrupts were initialized.

Hence replace setup_irq() by request_irq().

Seldom remove_irq() usage has been observed coupled with setup_irq(),
wherever that has been found, it too has been replaced by free_irq().

A build error that was reported by kbuild test robot <lkp@intel.com>
in the previous version of the patch also has been fixed.

[1] https://lkml.kernel.org/r/alpine.DEB.2.20.1710191609480.1971@nanosSigned-off-by: Nafzal mohammed <afzal.mohd.ma@gmail.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/91961c77c1cf93d41523f5e1ac52043f32f97077.1582799709.git.afzal.mohd.ma@gmail.com

X1000 has a different TCU containing OST, since X1000, OST has been
independent of TCU. This patch is prepare for later OST driver.
Signed-off-by: N周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/1582100974-129559-5-git-send-email-zhouyanjie@wanyeetech.com

Add the timer bindings for the X1000 Soc from Ingenic.
Signed-off-by: N周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/1582100974-129559-3-git-send-email-zhouyanjie@wanyeetech.com

The function omap_dm_timer_of_set_source() was originally added in
commit 31a7448f ("ARM: OMAP: dmtimer: Add clock source from DT"),
and is designed to set a clock source from DT using the clocks property
of a timer node. This design choice is okay for clk provider nodes but
otherwise is a bad design as typically the clocks property is used to
specify the functional clocks for a device, and not its parents.

The timer nodes now all define a timer functional clock after the
conversion to ti-sysc and the new clkctrl layout, and this results
in an attempt to set the same functional clock as its parent when a
consumer driver attempts to acquire any of these timers in the
omap_dm_timer_prepare() function. This was masked and worked around
in commit 983a5a43 ("clocksource: timer-ti-dm: Fix pwm dmtimer
usage of fck reparenting"). Fix all of this by simply dropping the
entire function.

Any DT configuration of clock sources should be achieved using
assigned-clocks and assigned-clock-parents properties provided
by the Common Clock Framework.

Cc: Tony Lindgren <tony@atomide.com>
Cc: Tero Kristo <t-kristo@ti.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: H. Nikolaus Schaller <hns@goldelico.com>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.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>
Signed-off-by: NSuman Anna <s-anna@ti.com>
Tested-by: NLokesh Vutla <lokeshvutla@ti.com>
Tested-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20200213053504.22638-1-s-anna@ti.com

Write to trigger register(OMAP_TIMER_TRIGGER_REG) will load the value
in Load register(OMAP_TIMER_LOAD_REG) into Counter register
(OMAP_TIMER_COUNTER_REG).

omap_dm_timer_set_load() writes into trigger register every time load
register is updated. When timer is configured in pwm mode, this causes
disruption in current pwm cycle, which is not expected especially when
pwm is used as PPS signal for synchronized PTP clocks. So do not write
into trigger register on updating the period.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Tested-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20200224050753.17784-3-lokeshvutla@ti.com

Check the return from clocksource_mmio_init, add messages in case of
an error and in case of not having a defined clock property.
Signed-off-by: NMatheus Castello <matheus@castello.eng.br>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20200219004810.411190-1-matheus@castello.eng.br

OST is the OS Timer, a 64-bit timer/counter with buffered reading.

SoCs before the JZ4770 had (if any) a 32-bit OST; the JZ4770 and
JZ4780 have a 64-bit OST.

This driver will register both a clocksource and a sched_clock to the
system.
Signed-off-by: NMaarten ter Huurne <maarten@treewalker.org>
Signed-off-by: NPaul Cercueil <paul@crapouillou.net>
Tested-by: NMathieu Malaterre <malat@debian.org>
Tested-by: NArtur Rojek <contact@artur-rojek.eu>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20200212180408.30872-1-paul@crapouillou.net

The ast2600 contains a fttmr010 derivative.
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NJoel Stanley <joel@jms.id.au>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20191107094218.13210-5-joel@jms.id.au

In preparation for supporting the ast2600, pass the shutdown and
interrupt functions to the common init callback.
Reviewed-by: NCédric Le Goater <clg@kaod.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NJoel Stanley <joel@jms.id.au>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20191107094218.13210-3-joel@jms.id.au

In preparation for supporting the ast2600 which uses a different method
to clear bits in the control register, use a callback for performing the
shutdown sequence.
Reviewed-by: NCédric Le Goater <clg@kaod.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NJoel Stanley <joel@jms.id.au>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20191107094218.13210-2-joel@jms.id.au

head is traversed using hlist_for_each_entry_rcu outside an RCU read-side
critical section but under the protection of hash_lock.

Hence, add corresponding lockdep expression to silence false-positive
lockdep warnings, and harden RCU lists.

[ tglx: Removed the macro and put the condition right where it's used ]
Signed-off-by: NAmol Grover <frextrite@gmail.com>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/20200216074330.GA14025@workstation-portable

When working commit 6dcd5d7a, a mistake was noticed by Linus:
schedule_timeout() was called without setting the task state to anything
particular.

It calls the scheduler, but doesn't delay anything, because the task stays
runnable. That happens because sched_submit_work() does nothing for tasks
in TASK_RUNNING state.

That turned out to be the intended behavior. Adding a WARN() is not useful
as the task could be woken up right after setting the state and before
reaching schedule_timeout().

Improve the comment about schedule_timeout() and describe that more
explicitly.
Signed-off-by: NAlexander Popov <alex.popov@linux.com>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/20200117225900.16340-1-alex.popov@linux.com

On powerpc, __arch_get_vdso_data() clobbers the link register, requiring
the caller to save it.

As the parent function already has to set a stack frame and saves the link
register before calling the C vdso function, retrieving the vdso data
pointer there is less overhead.

Split out the functional code from the __cvdso.*() interfaces into new
static functions which can either be called from the existing interfaces
with the vdso data pointer supplied via __arch_get_vdso_data() or directly
from ASM code.
Signed-off-by: NChristophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NVincenzo Frascino <vincenzo.frascino@arm.com>
Reviewed-by: NVincenzo Frascino <vincenzo.frascino@arm.com>
Link: https://lore.kernel.org/r/abf97996602ef07223fec30c005df78e5ed41b2e.1580399657.git.christophe.leroy@c-s.fr
Link: https://lkml.kernel.org/r/20200207124403.965789141@linutronix.de

On powerpc/32, GCC (8.1) generates pretty bad code for the ns >>= vd->shift
operation taking into account that the shift is always <= 32 and the upper
part of the result is likely to be zero. GCC makes reversed assumptions
considering the shift to be likely >= 32 and the upper part to be like not
zero.

unsigned long long shift(unsigned long long x, unsigned char s)
{
	return x >> s;
}

results in:

00000018 <shift>:
  18:	35 25 ff e0 	addic.  r9,r5,-32
  1c:	41 80 00 10 	blt     2c <shift+0x14>
  20:	7c 64 4c 30 	srw     r4,r3,r9
  24:	38 60 00 00 	li      r3,0
  28:	4e 80 00 20 	blr
  2c:	54 69 08 3c 	rlwinm  r9,r3,1,0,30
  30:	21 45 00 1f 	subfic  r10,r5,31
  34:	7c 84 2c 30 	srw     r4,r4,r5
  38:	7d 29 50 30 	slw     r9,r9,r10
  3c:	7c 63 2c 30 	srw     r3,r3,r5
  40:	7d 24 23 78 	or      r4,r9,r4
  44:	4e 80 00 20 	blr

Even when forcing the shift to be smaller than 32 with an &= 31, it still
considers the shift as likely >= 32.

Move the default shift implementation into an inline which can be redefined
in architecture code via a macro.

[ tglx: Made the shift argument u32 and removed the __arch prefix ]
Signed-off-by: NChristophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NVincenzo Frascino <vincenzo.frascino@arm.com>
Reviewed-by: NVincenzo Frascino <vincenzo.frascino@arm.com>
Link: https://lore.kernel.org/r/b3d449de856982ed060a71e6ace8eeca4654e685.1580399657.git.christophe.leroy@c-s.fr
Link: https://lkml.kernel.org/r/20200207124403.857649978@linutronix.de

Some architectures have a fixed clocksource which is known at compile time
and cannot be replaced or disabled at runtime, e.g. timebase on
PowerPC. For such cases the clock mode check in the VDSO code is pointless.

Move the check for a VDSO capable clocksource into an inline function and
allow architectures to redefine it via a macro.

[ tglx: Removed the #ifdef mess ]
Signed-off-by: NChristophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NVincenzo Frascino <vincenzo.frascino@arm.com>
Reviewed-by: NVincenzo Frascino <vincenzo.frascino@arm.com>
Link: https://lkml.kernel.org/r/20200207124403.748756829@linutronix.de

Move the time namespace indicator clock mode to the other ones for
consistency sake.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NVincenzo Frascino <vincenzo.frascino@arm.com>
Link: https://lkml.kernel.org/r/20200207124403.656097274@linutronix.de

If the current clocksource is not VDSO capable there is no point in
updating the high resolution parts of the VDSO data.

Replace the architecture specific check with a check for a VDSO capable
clocksource and skip the update if there is none.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NVincenzo Frascino <vincenzo.frascino@arm.com>
Reviewed-by: NVincenzo Frascino <vincenzo.frascino@arm.com>
Link: https://lkml.kernel.org/r/20200207124403.563379423@linutronix.de

Now that all architectures are converted to use the generic storage the
helpers and conditionals can be removed.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NVincenzo Frascino <vincenzo.frascino@arm.com>
Reviewed-by: NVincenzo Frascino <vincenzo.frascino@arm.com>
Link: https://lkml.kernel.org/r/20200207124403.470699892@linutronix.de

Convert ARM/ARM64 to the generic VDSO clock mode storage. This needs to
happen in one go as they share the clocksource driver.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NVincenzo Frascino <vincenzo.frascino@arm.com>
Reviewed-by: NVincenzo Frascino <vincenzo.frascino@arm.com>
Link: https://lkml.kernel.org/r/20200207124403.363235229@linutronix.de

Switch to the generic VDSO clock mode storage.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NVincenzo Frascino <vincenzo.frascino@arm.com>
Link: https://lkml.kernel.org/r/20200207124403.244684017@linutronix.de

Switch to the generic VDSO clock mode storage.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: Vincenzo Frascino <vincenzo.frascino@arm.com> (VDSO parts)
Acked-by: Juergen Gross <jgross@suse.com> (Xen parts)
Acked-by: Paolo Bonzini <pbonzini@redhat.com> (KVM parts)
Link: https://lkml.kernel.org/r/20200207124403.152039903@linutronix.de

All architectures which use the generic VDSO code have their own storage
for the VDSO clock mode. That's pointless and just requires duplicate code.

Provide generic storage for it. The new Kconfig symbol is intermediate and
will be removed once all architectures are converted over.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NVincenzo Frascino <vincenzo.frascino@arm.com>
Reviewed-by: NVincenzo Frascino <vincenzo.frascino@arm.com>
Link: https://lkml.kernel.org/r/20200207124403.028046322@linutronix.de

All architectures which use the generic VDSO code have their own storage
for the VDSO clock mode. That's pointless and just requires duplicate code.

X86 abuses the function which retrieves the architecture specific clock
mode storage to mark the clocksource as used in the VDSO. That's silly
because this is invoked on every tick when the VDSO data is updated.

Move this functionality to the clocksource::enable() callback so it gets
invoked once when the clocksource is installed. This allows to make the
clock mode storage generic.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>  (Hyper-V parts)
Reviewed-by: Vincenzo Frascino <vincenzo.frascino@arm.com> (VDSO parts)
Acked-by: Juergen Gross <jgross@suse.com> (Xen parts)
Link: https://lkml.kernel.org/r/20200207124402.934519777@linutronix.de

Reformat the struct definition, add missing member documentation.
No functional change.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NVincenzo Frascino <vincenzo.frascino@arm.com>
Link: https://lkml.kernel.org/r/20200207124402.825471920@linutronix.de

If neither the R4K nor the GIC timer is enabled in the kernel configuration
then let the core VDSO code drop the high resolution parts at compile time.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NVincenzo Frascino <vincenzo.frascino@arm.com>
Link: https://lkml.kernel.org/r/20200207124402.714585315@linutronix.de

If the architected timer is disabled in the kernel configuration then let
the core VDSO code drop the high resolution parts at compile time.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NVincenzo Frascino <vincenzo.frascino@arm.com>
Reviewed-by: NVincenzo Frascino <vincenzo.frascino@arm.com>
Link: https://lkml.kernel.org/r/20200207124402.622587341@linutronix.de

If the architecture knows at compile time that there is no VDSO capable
clocksource supported it makes sense to optimize the guts of the high
resolution parts of the VDSO out at build time. Add a helper function to
check whether the VDSO should be high resolution capable and provide a stub
which can be overridden by an architecture.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NVincenzo Frascino <vincenzo.frascino@arm.com>
Reviewed-by: NVincenzo Frascino <vincenzo.frascino@arm.com>
Link: https://lkml.kernel.org/r/20200207124402.530143168@linutronix.de

The function is nowhere used. Aside of that this check should only cover
the high resolution parts of the VDSO which require a VDSO capable
clocksource and not the complete functionality as the name suggests. Will
be replaced with something more useful.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NVincenzo Frascino <vincenzo.frascino@arm.com>
Reviewed-by: NVincenzo Frascino <vincenzo.frascino@arm.com>
Link: https://lkml.kernel.org/r/20200207124402.438179009@linutronix.de

Jumping out of line for the TSC clcoksource read is creating awful
code. TSC is likely to be the clocksource at least on bare metal and the PV
interfaces are sufficiently more work that the jump over the TSC read is
just in the noise.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NVincenzo Frascino <vincenzo.frascino@arm.com>
Link: https://lkml.kernel.org/r/20200207124402.328922847@linutronix.de

Pull IPMI update from Corey Minyard:
 "Minor bug fixes for IPMI

  I know this is late; I've been travelling and, well, I've been
  distracted.

  This is just a few bug fixes and adding i2c support to the IPMB
  driver, which is something I wanted from the beginning for it"

* tag 'for-linus-5.6-1' of https://github.com/cminyard/linux-ipmi:
  drivers: ipmi: fix off-by-one bounds check that leads to a out-of-bounds write
  ipmi:ssif: Handle a possible NULL pointer reference
  drivers: ipmi: Modify max length of IPMB packet
  drivers: ipmi: Support raw i2c packet in IPMB