There is no point in interposing on clock chip handlers for which
there was no support originally. In some cases (oneshot_stopped), we
may even get a kernel fault, jumping to a NULL address.

Interpose on non-NULL original handlers only.

Although we won't allow disabling the hardware when the clock event
logic switches a device to stopped mode - so that we won't affect the
timer logic running on the head stage unexpectedly -, we still have to
enable the hardware when switched (back) to oneshot mode, since it may
have been stopped prior to interposing on the device in
ipipe_timer_start().

Failing to do so would leave the hardware shut down for both regular
and Xenomai operations, with no mean to bring it up again.

Once the device was grabbed by ipipe_timer_start(), any pending host
tick programmed in the hardware is basically lost, unknown to the
co-kernel implementing the proxy handlers.

Schedule a host event with the latest target time programmed to have
the co-kernel know about the pending tick.

Handle requests for transitioning to deeper C-states the way Dovetail
does, which prevents us from losing the timer when grabbed by a
co-kernel, in presence of a CPUIDLE driver.

Those helpers affect both the real (in CPU) and virtual interrupt
states for the root stage, reconciling them.

At this chance, switch the min_delay_tick value to unsigned long to
match the corresponding clockevent definition.

Drop the legacy support for architectures not enabling the generic
clock event framework, which would only provide periodic timing.

We don't support any of those archs, and there is no point in running
a Xenomai co-kernel on a hardware not capable of handling oneshot
timing requests.

Fixes the kernel warning below due to the second enable sneaking in
between a thermal IRQ is handled by the hard interrupt handler - which
disables it - and the IRQ thread eventually attempts to re-enable the
interrupt - which was already enabled.

[    0.405830] Unbalanced enable for IRQ 44
[    0.406029] ------------[ cut here ]------------
[    0.406035] WARNING: CPU: 3 PID: 1285 at kernel/irq/manage.c:525 __enable_irq+0x60/0x70
[    0.406044] Modules linked in:
[    0.406055] CPU: 3 PID: 1285 Comm: irq/44-hisi_the Not tainted 4.14.62-ipipe #2
[    0.406060] Hardware name: HiKey Development Board (DT)
[    0.406065] I-pipe domain: Linux
[    0.406073] task: ffff8000336b0000 task.stack: ffff00000b9e0000
[    0.406078] PC is at __enable_irq+0x60/0x70
[    0.406083] LR is at __enable_irq+0x60/0x70
[    0.406088] pc : [<ffff000008124d58>] lr : [<ffff000008124d58>] pstate: 60000045
[    0.406093] sp : ffff00000b9e3c60
[    0.406098] x29: ffff00000b9e3c60 x28: 0000000000000000
[    0.406108] x27: ffff00000805ba40 x26: ffff8000336b0000
[    0.406118] x25: ffff000008124000 x24: ffff00000b9e3d7c
[    0.406128] x23: 0000000000000002 x22: ffff800033f39e88
[    0.406138] x21: 000000000000bc40 x20: 000000000000002c
[    0.406147] x19: ffff800034275200 x18: 0000000000000010
[    0.406157] x17: 0000000000000007 x16: 0000000000000001
[    0.406166] x15: ffff0000890014c7 x14: 0000000000000006
[    0.406175] x13: ffff0000090014d5 x12: ffff000008eb34d0
[    0.406184] x11: ffff000008eb3000 x10: 0000000005f5e0ff
[    0.406193] x9 : ffff00000b9e3970 x8 : 0000000000000040
[    0.406202] x7 : ffff000008e7c000 x6 : 0000000000000040
[    0.406211] x5 : 0000000000000000 x4 : 0000000000000000
[    0.406220] x3 : ffffffffffffffff x2 : ffff000008eb34f0
[    0.406229] x1 : ffff8000336b0000 x0 : 000000000000001c
[    0.406239] Call trace:
[    0.406244] Exception stack(0xffff00000b9e3b20 to 0xffff00000b9e3c60)
[    0.406249] 3b20: 000000000000001c ffff8000336b0000 ffff000008eb34f0 ffffffffffffffff
[    0.406255] 3b40: 0000000000000000 0000000000000000 0000000000000040 ffff000008e7c000
[    0.406261] 3b60: 0000000000000040 ffff00000b9e3970 0000000005f5e0ff ffff000008eb3000
[    0.406267] 3b80: ffff000008eb34d0 ffff0000090014d5 0000000000000006 ffff0000890014c7
[    0.406272] 3ba0: 0000000000000001 0000000000000007 0000000000000010 ffff800034275200
[    0.406278] 3bc0: 000000000000002c 000000000000bc40 ffff800033f39e88 0000000000000002
[    0.406284] 3be0: ffff00000b9e3d7c ffff000008124000 ffff8000336b0000 ffff00000805ba40
[    0.406289] 3c00: 0000000000000000 ffff00000b9e3c60 ffff000008124d58 ffff00000b9e3c60
[    0.406295] 3c20: ffff000008124d58 0000000060000045 0000000000000000 ffff800034275200
[    0.406300] 3c40: ffffffffffffffff ffff000008e7c2b0 ffff00000b9e3c60 ffff000008124d58
[    0.406306] [<ffff000008124d58>] __enable_irq+0x60/0x70
[    0.406311] [<ffff000008124d9c>] enable_irq+0x34/0x68
[    0.406317] [<ffff000008780320>] hisi_thermal_get_temp+0x160/0x198
[    0.406322] [<ffff00000877b868>] of_thermal_get_temp+0x20/0x30
[    0.406327] [<ffff00000877b0d4>] thermal_zone_get_temp+0x5c/0x138
[    0.406332] [<ffff000008778740>] thermal_zone_device_update.part.4+0x20/0xb0
[    0.406337] [<ffff0000087787f8>] thermal_zone_device_update+0x28/0x38
[    0.406342] [<ffff00000877fe7c>] hisi_thermal_alarm_irq_thread+0x64/0x80
[    0.406347] [<ffff0000081244e0>] irq_thread_fn+0x28/0x68
[    0.406352] [<ffff000008124784>] irq_thread+0x114/0x1b0
[    0.406357] [<ffff0000080f0384>] kthread+0xfc/0x128
[    0.406362] [<ffff000008085274>] ret_from_fork+0x14/0x20
[    0.406366] ---[ end trace 0e6011135c69587a ]---

Now that stop_machine() guarantees fully atomic execution of the stop
routine via hard interrupt disabling, there is no point in using
ipipe_critical_enter/exit() for the same purpose in order to patch the
kernel text.

stop_machine() guarantees that all online CPUs are spinning
non-preemptible in a known code location before a subset of them may
safely run a stop-context function. This service is typically useful
for live patching the kernel code, or changing global memory mappings,
so that no activity could run in parallel until the system has
returned to a stable state after all stop-context operations have
completed.

When interrupt pipelining is enabled, we have to provide the same
guarantee by restoring hard interrupt disabling where virtualizing the
interrupt disable flag would defeat it.

trace_hardirqs_on_virt[_caller]() must be invoked instead of
trace_hardirqs_on[_caller]() from assembly sites before returning from
an interrupt/fault, so that the virtual IRQ disable state is checked
for before switching the tracer's logic state to ON.

This is required as an interrupt may be received and handled by the
pipeline core although not forwarded to the root domain, when
interrupts are virtually disabled. In such a case, we want to
reconcile the tracer's logic with the effect of interrupt pipelining.

The lockdep engine will check for the current interrupt state as part
of the locking validation process, which must encompass:

- the CPU interrupt state
- the current pipeline domain
- the virtual interrupt disable flag

so that we can traverse the tracepoints from any context sanely and
safely.

In addition trace_hardirqs_on_virt_caller() should be called by the
arch-dependent code when tracking the interrupt state before returning
to user-space after a kernel entry (exceptions, IRQ). This makes sure
that the tracking logic only applies to the root domain, and considers
the virtual disable flag exclusively.

For instance, the kernel may be entered when interrupts are (only)
virtually disabled for the root domain (i.e. stalled), and we should
tell the IRQ tracing logic that IRQs are about to be enabled back only
if the root domain is unstalled before leaving to user-space. In such
a context, the state of the interrupt bit in the CPU would be
irrelevant.

Gilles Chanteperdrix authored Dec 03, 2017 and Philippe Gerum committed Nov 01, 2018

Fix up the PMU controller driver of the Marvell Dove SoC in order to
channel interrupts through the interrupt pipeline.

Fix up Synopsys's PCIE driver in order to channel interrupts through
the interrupt pipeline.

Fix up Altera's PCIE driver in order to channel interrupts through the
interrupt pipeline.

Fix up the pin controller driver of the Allwinner A1x SoCs in order to
channel interrupts through the interrupt pipeline.

Fix up the pin controller driver of the Broadcom 2835 SoC in order to
channel interrupts through the interrupt pipeline.

Greg Gallagher authored Feb 06, 2018 and Philippe Gerum committed Nov 01, 2018

Fix up the pin controller driver of the Rockchip SoC in order to
channel interrupts through the interrupt pipeline.

Enable the serial driver for raw_printk() output.

Enable the serial driver for raw_printk() output.

Enable the serial driver for raw_printk() output.

Fix up Freescale's general power controller driver in order to channel
interrupts through the interrupt pipeline.

Greg Gallagher authored Feb 06, 2018 and Philippe Gerum committed Nov 01, 2018

Fix up Broadcom's Generic Set Top Box (Level 2) interrupt controller
driver in order to channel interrupts through the interrupt pipeline.

Greg Gallagher authored Feb 06, 2018 and Philippe Gerum committed Nov 01, 2018

Fixup Broadcom's BCM7120 (Level 2) interrupt controller driver in
order to channel interrupts through the interrupt pipeline.

Greg Gallagher authored Feb 06, 2018 and Philippe Gerum committed Nov 01, 2018

Fix up ATMEL's AIC5 interrupt controller driver in order to channel
interrupts through the interrupt pipeline.

Gilles Chanteperdrix authored Dec 03, 2017 and Philippe Gerum committed Nov 01, 2018

Fix up the OMAP INTC interrupt controller driver in order to channel
interrupts through the interrupt pipeline.

Gilles Chanteperdrix authored Dec 03, 2017 and Philippe Gerum committed Nov 01, 2018

Fix up the OMAP GPMC interrupt controller driver in order to channel
interrupts through the interrupt pipeline.

Gilles Chanteperdrix authored Dec 03, 2017 and Philippe Gerum committed Nov 01, 2018

Fix up the ARM VIC interrupt controller driver in order to channel
interrupts through the interrupt pipeline.

Fix up the Versatile FPGA interrupt controller driver in order to
channel interrupts through the interrupt pipeline.