[PATCH v2] Add interrupt handling capability to pca953x

[Haojian Zhuang]

On Thu, Dec 24, 2009 at 7:16 PM, Eric Miao <eric.y.miao at gmail.com> wrote:
> On Fri, Dec 25, 2009 at 2:37 AM, Mark Brown
> <broonie at opensource.wolfsonmicro.com> wrote:
>> On Thu, Dec 24, 2009 at 06:52:40PM +0100, Marc Zyngier wrote:
>>
>>> Pending problems to be solved:
>>> - Modular build is broken, as handle_edge_irq, set_irq_flags and
>>>   irq_to_desc are not exported, among others. First approach would be
>>>   to disable the irq_chip when build modular, but I really don't like
>>>   it.
>>
>> The other approach here is just to not support modular builds; it's what
>> the IRQ core wants you to do and what I ended up doing for wm831x.  Or
>> speak to Ingo and Thomas and see if they'll relax the requirement that
>> interrupt controller drivers be built in.
>>
>>> - request_irq vs request_threaded_irq: genirq is a bit of a mess in
>>>   this respect. We'd love a consistent API...
>>
>> What's the problem here?  Are you referring to the consumer side or
>> something that the driver itself has to deal with - from the point of
>> view of the interrupt controller itself this is pretty much transparent.
>>
>> Like I said in my previous mail a threaded interrupt context is
>> fundamentally not a non-threaded one so users do need to be aware of
>> which context they're running in - you can do more things in a threaded
>> context but you also have more possibility for concurrency issues to
>> creep in.  This means that the visible difference between the two
>> handlers always seemed reasonable to me.

How about invoke local_irq_disable()/local_irq_enable() in
pxa953x_irq_handler()? If we do this, we can prevent concurrency in
customer IRQ handler that are depend on pxa953x_irq_handler().

>>
>> It would be nice to have a third option for handlers which can cope with
>> either context, though.  Actually, using request_threaded_irq and
>> supplying the same function for both primary and secondary handler may
>> DTRT in that case but I'd need to check.  This is another thing we
>> really ought to bring up with Ingo and Thomas rather than discussing
>> here, though.
>>
>
> Then, let's get them involved. Thomas and Ingo CC'ed.
>