linux.git/drivers/clocksource, branch v5.8-rc2

clocksource/drivers/timer-riscv: Use per-CPU timer interrupt

2020-06-10T02:11:22+00:00

Instead of directly calling RISC-V timer interrupt handler from
RISC-V local interrupt conntroller driver, this patch implements
RISC-V timer interrupt as a per-CPU interrupt using per-CPU APIs
of Linux IRQ subsystem.

Signed-off-by: Anup Patel 
Reviewed-by: Atish Patra 
Reviewed-by: Marc Zyngier 
Signed-off-by: Palmer Dabbelt

clocksource/drivers/timer-versatile: Clear OF_POPULATED flag

2020-05-22T22:03:25+00:00

The commit 4f41fe386a94 ("clocksource/drivers/timer-probe: Avoid
creating dead devices") broke the handling of arm,vexpress-sysreg [1].

The arm,vexpress-sysreg device is handled by both timer-versatile.c and
drivers/mfd/vexpress-sysreg.c. While the timer driver doesn't use the
device, the mfd driver still needs a device to probe.

So, this patch clears the OF_POPULATED flag to continue creating the
device.

[1] - https://lore.kernel.org/lkml/20200324175955.GA16972@arm.com/

Fixes: 4f41fe386a94 ("clocksource/drivers/timer-probe: Avoid creating dead devices")
Signed-off-by: Saravana Kannan 
Signed-off-by: Daniel Lezcano 
Link: https://lore.kernel.org/r/20200324195302.203115-1-saravanak@google.com

clocksource: mips-gic-timer: Mark GIC timer as unstable if ref clock changes

2020-05-22T22:03:16+00:00

Currently clocksource framework doesn't support the clocks with variable
frequency. Since MIPS GIC timer ticks rate might be unstable on some
platforms, we must make sure that it justifies the clocksource
requirements. MIPS GIC timer is incremented with the CPU cluster reference
clocks rate. So in case if CPU frequency changes, the MIPS GIC tick rate
changes synchronously. Due to this the clocksource subsystem can't rely on
the timer to measure system clocks anymore. This commit marks the MIPS GIC
based clocksource as unstable if reference clock (normally it's a CPU
reference clocks) rate changes. The clocksource will execute a watchdog
thread, which lowers the MIPS GIC timer rating to zero and fallbacks to a
new stable one.

Note we don't need to set the CLOCK_SOURCE_MUST_VERIFY flag to the MIPS
GIC clocksource since normally the timer is stable. The only reason why
it gets unstable is due to the ref clock rate change, which event we
detect here in the driver by means of the clocks event notifier.

Signed-off-by: Serge Semin 
Cc: Alexey Malahov 
Cc: Thomas Bogendoerfer 
Cc: Paul Burton 
Cc: Ralf Baechle 
Cc: Alessandro Zummo 
Cc: Alexandre Belloni 
Cc: Arnd Bergmann 
Cc: Rob Herring 
Cc: linux-mips@vger.kernel.org
Cc: linux-rtc@vger.kernel.org
Cc: devicetree@vger.kernel.org
Signed-off-by: Daniel Lezcano 
Link: https://lore.kernel.org/r/20200521204818.25436-9-Sergey.Semin@baikalelectronics.ru

clocksource: mips-gic-timer: Register as sched_clock

2020-05-22T22:03:08+00:00

The MIPS GIC timer is well suited for use as sched_clock, so register it
as such.

Whilst the existing gic_read_count() function matches the prototype
needed by sched_clock_register() already, we split it into 2 functions
in order to remove the need to evaluate the mips_cm_is64 condition
within each call since sched_clock should be as fast as possible.

Note the sched clock framework needs the clock source being stable in
order to rely on it. So we register the MIPS GIC timer as schedule clocks
only if it's, if either the system doesn't have CPU-frequency enabled or
the CPU frequency is changed by means of the CPC core clock divider
available on the platforms with CM3 or newer.

Signed-off-by: Paul Burton 
Co-developed-by: Serge Semin 
[Sergey.Semin@baikalelectronics.ru: Register sched-clock if CM3 or !CPU-freq]
Signed-off-by: Serge Semin 
Cc: Alexey Malahov 
Cc: Thomas Bogendoerfer 
Cc: Ralf Baechle 
Cc: Alessandro Zummo 
Cc: Alexandre Belloni 
Cc: Arnd Bergmann 
Cc: Rob Herring 
Cc: linux-mips@vger.kernel.org
Cc: linux-rtc@vger.kernel.org
Cc: devicetree@vger.kernel.org
Signed-off-by: Daniel Lezcano 
Link: https://lore.kernel.org/r/20200521204818.25436-8-Sergey.Semin@baikalelectronics.ru

clocksource: dw_apb_timer_of: Fix missing clockevent timers

2020-05-22T22:02:59+00:00

Commit 100214889973 ("clocksource: dw_apb_timer_of: use
clocksource_of_init") replaced a publicly available driver
initialization method with one called by the timer_probe() method
available after CLKSRC_OF. In current implementation it traverses
all the timers available in the system and calls their initialization
methods if corresponding devices were either in dtb or in acpi. But
if before the commit any number of available timers would be installed
as clockevent and clocksource devices, after that there would be at most
two. The rest are just ignored since default case branch doesn't do
anything. I don't see a reason of such behaviour, neither the commit
message explains it. Moreover this might be wrong if on some platforms
these timers might be used for different purpose, as virtually CPU-local
clockevent timers and as an independent broadcast timer. So in order
to keep the compatibility with the platforms where the order of the
timers detection has some meaning, lets add the secondly discovered
timer to be of clocksource/sched_clock type, while the very first and
the others would provide the clockevents service.

Fixes: 100214889973 ("clocksource: dw_apb_timer_of: use clocksource_of_init")
Signed-off-by: Serge Semin 
Cc: Alexey Malahov 
Cc: Thomas Bogendoerfer 
Cc: Paul Burton 
Cc: Ralf Baechle 
Cc: Alessandro Zummo 
Cc: Alexandre Belloni 
Cc: Arnd Bergmann 
Cc: Rob Herring 
Cc: linux-mips@vger.kernel.org
Cc: linux-rtc@vger.kernel.org
Cc: devicetree@vger.kernel.org
Signed-off-by: Daniel Lezcano 
Link: https://lore.kernel.org/r/20200521204818.25436-7-Sergey.Semin@baikalelectronics.ru

clocksource: dw_apb_timer: Affiliate of-based timer with any CPU

2020-05-22T22:02:50+00:00

Currently any DW APB Timer device detected in OF is bound to CPU #0.
Doing so is redundant since DW APB Timer isn't CPU-local timer, but as
having APB interface is normally accessible from any CPU in the system. By
artificially affiliating the DW timer to the very first CPU we may and in
our case will make the clockevent subsystem to decline the more performant
real CPU-local timers selection in favor of in fact non-local and
accessible over a slow bus - DW APB Timers.

Let's not affiliate the of-detected DW APB Timers to any CPU. By doing so
the clockevent framework would prefer to select the real CPU-local timer
instead of DW APB one. Otherwise if there is no other than DW APB device
for clockevents tracking then it will be selected.

Signed-off-by: Serge Semin 
Cc: Alexey Malahov 
Cc: Thomas Bogendoerfer 
Cc: Paul Burton 
Cc: Ralf Baechle 
Cc: Alessandro Zummo 
Cc: Alexandre Belloni 
Cc: Arnd Bergmann 
Cc: Rob Herring 
Cc: linux-mips@vger.kernel.org
Cc: linux-rtc@vger.kernel.org
Cc: devicetree@vger.kernel.org
Signed-off-by: Daniel Lezcano 
Link: https://lore.kernel.org/r/20200521204818.25436-6-Sergey.Semin@baikalelectronics.ru

clocksource: dw_apb_timer: Make CPU-affiliation being optional

2020-05-22T22:02:41+00:00

Currently the DW APB Timer driver binds each clockevent timers to a
particular CPU. This isn't good for multiple reasons. First of all seeing
the device is placed on APB bus (which makes it accessible from any CPU
core), accessible over MMIO and having the DYNIRQ flag set we can be sure
that manually binding the timer to any CPU just isn't correct. By doing
so we just set an extra limitation on device usage. This also doesn't
reflect the device actual capability, since by setting the IRQ affinity
we can make it virtually local to any CPU. Secondly imagine if you had a
real CPU-local timer with the same rating and the same CPU-affinity.
In this case if DW APB timer was registered first, then due to the
clockevent framework tick-timer selection procedure we'll end up with the
real CPU-local timer being left unselected for clock-events tracking. But
on most of the platforms (MIPS/ARM/etc) such timers are normally embedded
into the CPU core and are accessible with much better performance then
devices placed on APB. For instance in MIPS architectures there is
r4k-timer, which is CPU-local, assigned with the same rating, and normally
its clockevent device is registered after the platform-specific one.

So in order to fix all of these issues let's make the DW APB Timer CPU
affinity being optional and deactivated by passing a negative CPU id,
which will effectively set the DW APB clockevent timer cpumask to
'cpu_possible_mask'.

Signed-off-by: Serge Semin 
Cc: Alexey Malahov 
Cc: Thomas Bogendoerfer 
Cc: Paul Burton 
Cc: Ralf Baechle 
Cc: Alessandro Zummo 
Cc: Alexandre Belloni 
Cc: Arnd Bergmann 
Cc: Rob Herring 
Cc: linux-mips@vger.kernel.org
Cc: linux-rtc@vger.kernel.org
Cc: devicetree@vger.kernel.org
Signed-off-by: Daniel Lezcano 
Link: https://lore.kernel.org/r/20200521204818.25436-5-Sergey.Semin@baikalelectronics.ru

clocksource/drivers/timer-ti-dm: Do one override clock parent in prepare()

2020-05-22T22:02:05+00:00

omap_dm_timer_prepare() is setting up the parent 32KHz clock. This
prepare() gets called by request_timer in the client's driver. Because of
this, the timer clock parent that is set with assigned-clock-parent is being
overwritten. So drop this default setting of parent in prepare().

Signed-off-by: Lokesh Vutla 
Reviewed-by: Suman Anna 
Acked-by: Tony Lindgren 
Signed-off-by: Daniel Lezcano 
Link: https://lore.kernel.org/r/20200427172831.16546-1-lokeshvutla@ti.com

clocksource/drivers/timer-ti-dm: Fix spelling mistake "detectt" -> "detect"

2020-05-22T22:01:35+00:00

There is a spelling mistake in a pr_err message. Fix it.

Signed-off-by: Colin Ian King 
Signed-off-by: Daniel Lezcano 
Link: https://lore.kernel.org/r/20200519224428.6195-1-colin.king@canonical.com

Merge branch 'timers/drivers/timer-ti' into timers/drivers/next

2020-05-22T22:01:13+00:00