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;
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.
2014/1/15 Mark Brown <[email protected]>:
> 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.
On Thu, Jan 16, 2014 at 07:33:13PM +0800, Yi Zhang wrote:
> 2014/1/15 Mark Brown <[email protected]>:
> > 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.