[PATCH] ARM: gic: use handle_fasteoi_irq for SPIs

[adharmap@codeaurora.org (Abhijeet Dharmapurikar)]

>> Right, so to get back to the original discussion about how to handle
>> chained handlers if the high-level flow type of the IRQ chip is altered
>> it seems that there are two options:
>>
>> 1.) Update all of the chained handlers to use the new flow-control
>> 2.) Retain backwards compatibility if a chained handler decides to
>>     use the old method of flow control (specifically, leave an ack
>>     implementation in the GIC code after moving to fasteoi).
>>
>> Obviously, I'd rather go with option (2) and let platforms migrate
>> over time if they choose to. Now, given that the ack function is really
>> not something you want to do in a virtualised environment (because it
>> pokes the distributor), is it worth sticking a
>> WARN_ON_ONCE(cpu_has_virtualisation()); in the ack code?
> 
> #2 is less painful and just works. The fasteoi stuff does not use ack
> IIRC so it wont hurt.

On an MSM we use handle_percpu_irq for PPIs, if we have ack and eoi we 
will end up EOI ing the interrupt twice so #2 wont work. Also all the 
cascaded handlers would have assumed that the ack function masks the 
interrupt, it is best we fix all of them to use eoi at the end (just 
like handle_fasteoi_irq). Please tell me how you guys locate such 
cascaded handlers?

Sorry for my earlier patch - didnt realize that the chaging the ack will 
break the chained handler. My board doesnt have cascaded gics. The only 
chained handler I knew was gpio-v2.c and it does the correct thing of 
calling an desc->chip->ack at the end.

BTW, I am all in favor of using handle_fasteoi_irq for shared PPIs , It 
will fix a problem I pointed out here.
http://kerneltrap.org/mailarchive/linux-kernel/2010/12/30/4664338

--
Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm 
Innovation Center, Inc. is a member of the Code Aurora Forum.