On 06/06/14 08:46, Peter De Schrijver wrote:
@@ -1037,17 +1076,28 @@ void __init gic_init_bases(unsigned int gic_nr, int irq_start, irq_base = irq_start; }
gic->domain = irq_domain_add_legacy(node, gic_irqs, irq_base,hwirq_base, &gic_irq_domain_ops, gic);
gic->domain =irq_domain_add_legacy(node, 2 * gic_irqs, irq_base,hwirq_base, &gic_irq_domain_ops, gic);
gic->domain = irq_domain_add_linear(node, nr_routable_irqs,&gic_irq_domain_ops,gic);
gic->domain = irq_domain_add_linear(node, 2 * nr_routable_irqs,&gic_irq_domain_ops, gic);if (WARN_ON(!gic->domain)) return; +#ifdef CONFIG_FIQ
- /* FIQ can only be supported on platforms without an extended irq_eoi
* method (otherwise we take a lock during irq_eoi handling).*/- if (!gic_arch_extn.irq_eoi)
fiq_add_mapping(irq_linear_revmap(gic->domain, hwirq_base),irq_linear_revmap(gic->domain, hwirq_base + gic_irqs),gic_irqs);+#endif
This is rather unfortunate. On Tegra for example we don't need a lock for the irq_eoi because the eoi ack can be handled with a single write to the appropriate irq ack register.
I believe that Tegra is the only platform that uses this hook so should be safe to remove the locks from gic_irq_eoi().
Certainly looking back at the code history and the mailing list discussions around this code[1] I cannot see any reasoning about the locks that I have missed.
Any objections to just nuking the locks?
Daniel.
[1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/107474 http://thread.gmane.org/gmane.linux.ports.arm.kernel/108361 http://thread.gmane.org/gmane.linux.ports.arm.kernel/109690