Re: [Question] Should we make the primary interrupt handler configurable for regmap_add_irq_chip()?

On Thu, Jan 16, 2014 at 07:33:13PM +0800, Yi Zhang wrote: > 2014/1/15 Mark Brown : > > On Sat, Jan 11, 2014 at 12:15:21PM +0800, Yi Zhang wrote: > >> I met a scenario: > >> As soon as the interrupt is triggered, a wakelock is needed to be held > >> until the threaded handler finishes, > >> I think

Re: [Question] Should we make the primary interrupt handler configurable for regmap_add_irq_chip()?

2014/1/15 Mark Brown : > On Sat, Jan 11, 2014 at 12:15:21PM +0800, Yi Zhang wrote: > >> I met a scenario: >> As soon as the interrupt is triggered, a wakelock is needed to be held >> until the threaded handler finishes, >> I think we may hold it in the primary interrupt handler, but now it's >> NUL

Re: [Question] Should we make the primary interrupt handler configurable for regmap_add_irq_chip()?

On Sat, Jan 11, 2014 at 12:15:21PM +0800, Yi Zhang wrote: > I met a scenario: > As soon as the interrupt is triggered, a wakelock is needed to be held > until the threaded handler finishes, > I think we may hold it in the primary interrupt handler, but now it's > NULL by default; This sounds like

[Question] Should we make the primary interrupt handler configurable for regmap_add_irq_chip()?

Hi, Mark: Sorry to trouble you; I have a question about the regmap_add_irq_chip(): at present, we use the default primary interrupt handler to handle the parent interrupt from a mfd device; I met a scenario: As soon as the interrupt is triggered, a wakelock is needed to be held until the threaded