[RFC v3 4/9] irqchip: gic: Introduce shadow irqs for FIQ

[Daniel Thompson]

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);
>>  	} else {
>> -		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