lkml.org 
[lkml]   [2014]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH V3 3/3] mfd: palmas: Add support for optional wakeup
* Thomas Gleixner <tglx@linutronix.de> [140919 12:47]:
> On Fri, 19 Sep 2014, Tony Lindgren wrote:
> > * Thomas Gleixner <tglx@linutronix.de> [140919 10:37]:
> > >From hardware point of view the wake-up events behave like interrupts
> > and could also be used as the only interrupt in some messed up cases.
> > That avoids all kinds of custom APIs from driver point.
> >
> > The re-entrancy problem we've most likely had ever since we enabled
> > the PRCM interrupts, and maybe that's why I did not even consider
> > that part. I think before that we were calling the driver interrupt
> > after waking up from the PM code..
> >
> > Anyways, how about the following to deal with the re-entrancy problem:
> >
> > 1. The wake-up interrupt handler must have a separate interrupt
> > handler that just calls tasklet_schedule()
> >
> > 2. The device interrupt handler also just calls tasklet_schedule()
> >
> > 3. The tasklet then does pm_runtime_get, handles the registers, and
> > so on.
> >
> > Or would we still have a re-entrancy problem somewhere else with
> > that?
>
> Why on earth are you wanting tasklets in there? That's just silly,
> really.

Lack of a framework on driver side to cope with this in a generic
way? :p

> The wakeup handler is supposed to bring the thing out of deep sleep
> and nothing else. All you want it to do is to mask itself and save the
> information that the real device irq is pending.

Yes that is enough.

> A stub handler for the wakeup irq is enough. We can have that in the
> irq/pm core and all it would do is simply:
>
> irqreturn_t handle_jinxed_wakeup_irq(unsigned irq, void *dev_id)
> {
> unsigned device_irq = get_dev_irq(dev_id);
>
> force_mask(irq);
> set_irq_pending(device_irq);
> return HANDLED;
> }
>
> So on resume_device_irqs() the real device interrupt gets reenabled
> and unmasked (if it was masked) and the interrupt gets resent either
> in hardware (level or retrigger) or by the software resend mechanism.
>
> That completely avoids tasklets, reentrant irq handlers and all other
> crap which might be required.

Okie dokie, that sounds good to me. Having this generic for the
drivers would be excellent, that's the missing piece.

Thanks,

Tony


\
 
 \ /
  Last update: 2014-09-19 22:21    [W:0.080 / U:1.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site