OMAP gpio driver was changed upstream to be able to support threaded IRQ handler,
this change impacted how the ipipe dealt with this driver. Since the ipipe expects
a chained handler and now it's a generic one, we need to ack the event in the
interrupt controller before calling the handler and unmask it after.

Level flow handler must be used for pipelined interrupts. Since the IRQ handler
 on the root stage may be delayed until the real-time core releases the CPU, we
need to mask the IRQ to prevent an IRQ storm when the interrupts are enabled again.

Convert wa_lock to ipipe_spinlock, since wa_lock is used in the irq_chip functions
which when called from the head stage can't use a Linux kernel service.

Add the hold/release handlers for robustness.
Signed-off-by: Greg Gallagher <greg@embeddedgreg.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

When a huge number of CPUs is available (e.g. CONFIG_MAXSMP/x86), we
might overflow the stack with cpumask_t variables in
ipipe_select_timer(). Allocate the cpumask we need there dynamically
instead.

When a huge number of CPUs is available (e.g. CONFIG_MAXSMP/x86), we
might overflow the stack with cpumask_t variables in
ipipe_critical_enter().

Instead of allocating cpumask_var_t dynamically for these, rely on the
fact that we cannot reenter the code accessing them by design, so
those variables may be moved to local static storage.

Some configurations may define more than 256K distinct interrupts
(e.g. CONFIG_MAXSMP/x86), which is the limit for the current 3-level
mapping used for logging IRQs. Add a 4th mapping level to support
configurations up to 16M interrupts.

This is a pretty bad issue affecting the logic involved in reconciling
the virtual interrupt state with the hardware interrupt flags received
on entry to any CPU exception.

The net effect was a potentially corrupted virtual interrupt state on
exit from the fault handlers.

Needed on x86 at least when CONFIG_IPIPE is off.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

x86 may generate one, so change the signature.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

Likely needed since c942cee4 which split enabling and startup.

This fixes unpopulated vectors in the IOAPIC on x86 at least, possibly
more.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

It's time to let ipipe_enable_irq return a proper error as it will gain
another function that may fail. Drop the WARN_ON_ONCE in favor of that.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

Breaks in non-debug builds otherwise, e.g.
https://travis-ci.com/xenomai-ci/xenomai/jobs/212725223Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

All callers of lockdep_hardirqs_on/off already filter out !ipipe_root_p.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

Lost in d7fc2c06 ("lockdep: ipipe: exclude the head stage from IRQ
state tracing") but still needed by x86 at least.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

These changes are paired with updates to lockdep+ftrace in order to
keep the (perceived) IRQ state consistent with the expectations of the
latter.

Bottom line: IRQ events which preempt the root stage while stalled
must not alter the tracer state incorrectly.

The change in #5a7e6eeede58 does not fix the root issue, but causes
__ipipe_tsc_register() to refer to .init data which is a section
violation too. Unfortunately, __ipipe_tsc_register() may be called
long after boot when loading a clocksource dynamically (which is what
the above commit was trying to address), but the position of TSC
helpers in the KUSER page depends on other -unrelated- helpers so we
have to define them in the same section.

To escape this stalemate, move the whole KUSER setup code and
variables outside of the .init section (TSC and other helpers), which
should only amount to a few hundreds of bytes.

CONFIG_DEBUG_SECTION_MISMATCH=y reports:

The function dw_apb_clocksource_register() references
the function __init __ipipe_tsc_register().
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

This adds the arm-specific bits to implement the userspace return
notifier.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

Although the regular SMP code is fine with keeping IPI_CPU_BACKTRACE
out of this count, we don't as we depend on it to figure out the exact
number of IPI vectors in use. The last IPI number we must allocate is
NR_IPI + IPIPE_LAST_IPI + 1, to account for the empty CPU_BACKTRACE
slot.

This bug badly breaks ipipe_raise_irq() by causing a conflict in the
VIRQ namespace between the last IPI and the first allocated VIRQ
allocated by the generic code (detected with deferred out-of-band
printk() messages not showing up).

Something moved the value of this constant but didn't update the
hard-coded instances. Fix this and avoid future problems by using the
proper symbolic value.

That just requires harding asm/ipipe_base.h for assembly use.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

The mayday trap asks the co-kernel to deal with a runaway context
which has been detected earlier. When doing so, the co-kernel might
re-enable hard interrupts, which we have to disable again before
unwinding the IRQ context which triggered the whole process (like a
watchdog event).

Use __ipipe_call_mayday() to fire the notification to the co-kernel
instead of the open coded version, so that we do restore the hard
interrupt state properly before leaving __ipipe_exit_irq().