kernel.git/arch/arc/kernel/intc-arcv2.c, branch linux-4.11.y

ARCv2: intc: Set default priority for all core interrupts

2017-02-06T17:37:57Z

After reset all interrupts in the core interrupt controller has the highest priority P0. If the platform supports Fast IRQs and has more than 1 banks of registers then CPU automatically switch banks of registers when P0 interrupt comes. The problem is that the kernel expects that by default switching of banks is not used by all interrupts. It is necessary to set a default nonzero priority for all available interrupts to avoid undefined behaviour. Signed-off-by: Yuriy Kolerov Signed-off-by: Vineet Gupta

ARCv2: intc: Use runtime value of irq count for setting up intc

2017-02-06T17:37:57Z

Signed-off-by: Vineet Gupta

ARC: [intc-*]: confine NR_CPU_IRQS to intc code

2017-02-06T17:37:57Z

And even this willl change in subsequent patches where we resort to using run time info instead... Signed-off-by: Vineet Gupta

ARCv2: intc: Use ARC_REG_STATUS32 for addressing STATUS32 reg

2017-02-06T17:37:57Z

It is better to use it instead of magic numbers. Signed-off-by: Yuriy Kolerov Signed-off-by: Vineet Gupta

ARC: IRQ: Use hwirq instead of virq in mask/unmask

2017-01-05T01:12:10Z

It is necessary to use hwirq instead of virq when you communicate with an interrupt controller since there is no guaranty that virq numbers match hwirq numbers. Signed-off-by: Yuriy Kolerov Signed-off-by: Vineet Gupta

ARCv2: intc: default all interrupts to priority 1

2016-12-14T17:23:46Z

ARC HS Cores support configurable multiple interrupt priorities of upto 16 levels. In commit dec2b2849cfcc ("ARCv2: intc: Allow interruption by lowest priority interrupt") we switched to 15 which seems a bit excessive given that there would be rare hardware implementing so many preemption levels AND running Linux. It would seem that 2 levels will be more common so switch to 1 as the default priority level. This will be the "lower" priority level saving 0 for implementing NMI style support. This scheme also works in systems with more than 2 prioity levels as well. Signed-off-by: Vineet Gupta

ARCv2: intc: Use kflag if STATUS32.IE must be reset

2016-09-30T21:48:24Z

In the end of "arc_init_IRQ" STATUS32.IE flag is going to be affected by "flag" instruction but "flag" never touches IE flag on ARCv2. So "kflag" instruction must be used instead of "flag". Signed-off-by: Yuriy Kolerov Cc: stable@vger.kernel.org #4.2+ Signed-off-by: Vineet Gupta

ARC: [intc-*] switch to linear domain

2016-05-09T04:02:30Z

Now that we have Timers probed from DT, don't need legacy domain This however requires mapping to be called explicitly for the IRQ which still can't (and probably never) be probed from DT such as IPI and SOFTIRQ Acked-by: Marc Zyngier Signed-off-by: Vineet Gupta

ARC: [intc-*] Do a domain lookup in primary handler for hwirq -> linux virq

2016-05-09T04:02:30Z

The primary interrupt handler arch_do_IRQ() was passing hwirq as linux virq to core code. This was fragile and worked so far as we only had legacy/linear domains. This came out of a rant by Marc Zyngier. http://lists.infradead.org/pipermail/linux-snps-arc/2015-December/000298.html Cc: Marc Zyngier Cc: Thomas Gleixner Cc: Noam Camus Signed-off-by: Vineet Gupta

ARCv2: intc: Allow interruption by lowest priority interrupt

2016-02-10T01:08:50Z

ARC HS Cores support configurable multiple interrupt priorities of upto 16 levels. There is processor "interrupt preemption threshhold" in STATUS32.E[4:1] And several places need to set this up: 1. seed value as kernel is booting 2. seed value for user space programs 3. Arg to SLEEP instruction in idle task (what interrupt prio can wake) 4. Per-IRQ line prioirty (i.e. what is the priority of interrupt raised by a peripheral or timer or perf counter... Currently above sites use the highest priority 0. This can be potential problem when multiple priorities are supported. e.g. user space could only be interrupted by P0 interrupt, not others... So turn this over and instead make default interruption level to be the lowest priority possible 15. This should be fine even if there are fewer priority levels configured (say two: P0 HIGH, P1 LOW) This feature also effectively disables FIRQ feature if present in hardware config. With old code, a P0 interrupt would be FIRQ, needing special handling (ISR or Register Banks) which is NOT supported yet. Now it not be P0 (P15 or whatever is lowest prio) so FIRQ is not triggered. Signed-off-by: Vineet Gupta