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

[Yi Zhang]

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 handler finishes,
I think we may hold it in the primary interrupt handler, but now it's
NULL by default;

so could we make the the primary interrupt handler configurable? for
example, add a parameter to regmap_add_irq_chip(),
then the user can choose to use current solution or his/her own handler;

what do you think?
could you please share your opinion?

thanks very much;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[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
> NULL by default;

This sounds like something we should just support in the core, though to
be honest I'd expect the interrupt core to hold a wakelock itself during
interrupt processing. If we're doing it in regmap then allowing the
caller to set a wakelock to hold seems better than making them all write
the code to take and release it.

[Yi Zhang]

2014/1/15 Mark Brown <bro...@kernel.org>:

> 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 something we should just support in the core, though to

Sorry, I'm not clear about this, you mean that this has been supported
in regmap framework?
I searched but didn't find related mail about this, could you please
kindly point out the mail loop?
thanks very much;

> be honest I'd expect the interrupt core to hold a wakelock itself during
> interrupt processing. If we're doing it in regmap then allowing the
> caller to set a wakelock to hold seems better than making them all write
> the code to take and release it.

[Mark Brown]

On Thu, Jan 16, 2014 at 07:33:13PM +0800, Yi Zhang wrote:
> 2014/1/15 Mark Brown <bro...@kernel.org>:
> > 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 something we should just support in the core, though to

> Sorry, I'm not clear about this, you mean that this has been supported
> in regmap framework?
> I searched but didn't find related mail about this, could you please
> kindly point out the mail loop?
> thanks very much;

I'm saying we should support it in the core rather than providing a way
to override the handlers - it seems like it'll be sufficiently common
that we'll rapidly end up with multiple implementations anyway. It
isn't currently supported in the core though, someone would need to
write that code.