On Fri, Nov 14, 2014 at 09:08:17AM -0800, Tony Lindgren wrote:
> * Felipe Balbi [141114 08:20]:
> > On Thu, Nov 13, 2014 at 09:40:31AM -0800, Tony Lindgren wrote:
> > > +/**
> > > + * handle_wakeirq_thread - call device runtime pm calls on wake-up
> > > interrupt
> > > + * @wakeirq: d
* Felipe Balbi [141114 08:20]:
> On Thu, Nov 13, 2014 at 09:40:31AM -0800, Tony Lindgren wrote:
> > +/**
> > + * handle_wakeirq_thread - call device runtime pm calls on wake-up
> > interrupt
> > + * @wakeirq: device specific wake-up interrupt
> > + * @dev_id: struct device entry
> > + */
> > +irq
Hi,
On Thu, Nov 13, 2014 at 09:40:31AM -0800, Tony Lindgren wrote:
[snip]
> From: Tony Lindgren
> Date: Tue, 11 Nov 2014 07:53:55 -0800
> Subject: [PATCH] genirq: Add support for wake-up interrupts to fix irq
> reentry issues in drivers
>
> As pointed out by Thomas Gleixner, at least omap wak
* Thomas Gleixner [141113 14:27]:
> On Thu, 13 Nov 2014, Tony Lindgren wrote:
> > Oops thanks for catching that. As the devres stuff is separate, I've
> > updated the patch to keep it that way by adding a minimal manage.h.
> > This avoids including internals.h in devres.c. Does that seem usable
>
On Thu, 13 Nov 2014, Tony Lindgren wrote:
> Oops thanks for catching that. As the devres stuff is separate, I've
> updated the patch to keep it that way by adding a minimal manage.h.
> This avoids including internals.h in devres.c. Does that seem usable
> for you?
What's wrong with internals.h? de
* Thomas Gleixner [141113 02:04]:
> Tony,
>
> On Thu, 6 Nov 2014, Tony Lindgren wrote:
> >
> > Any comments on the patch below? Let me know if you want to keep the
> > devm stuff out of kernel/irq/manage.c.
>
> Sorry, this slipped through the cracks.
No problem I should have posted it as a sep
Tony,
On Thu, 6 Nov 2014, Tony Lindgren wrote:
>
> Any comments on the patch below? Let me know if you want to keep the
> devm stuff out of kernel/irq/manage.c.
Sorry, this slipped through the cracks.
> > +static int setup_wakeirq(struct device *dev, unsigned int wakeirq,
> > +
Thomas,
Any comments on the patch below? Let me know if you want to keep the
devm stuff out of kernel/irq/manage.c.
* Tony Lindgren [141001 20:45]:
> Hi Thomas,
>
> * Thomas Gleixner [140919 12:47]:
> >
> > The wakeup handler is supposed to bring the thing out of deep sleep
> > and nothing el
Hi Thomas,
* Thomas Gleixner [140919 12:47]:
>
> 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.
>
> A stub handler for the wakeup irq is enough. We ca
* Thomas Gleixner [140919 19:08]:
> On Fri, 19 Sep 2014, Tony Lindgren wrote:
> > * Thomas Gleixner [140919 12:47]:
> > > 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
>
> So
On Fri, 19 Sep 2014, Tony Lindgren wrote:
> * Thomas Gleixner [140919 12:47]:
> > 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
So instead of creating such a thing we rather have a co
* Thomas Gleixner [140919 12:47]:
> On Fri, 19 Sep 2014, Tony Lindgren wrote:
> > * Thomas Gleixner [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 cus
On Fri, 19 Sep 2014, Tony Lindgren wrote:
> * Thomas Gleixner [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-entra
* Thomas Gleixner [140919 10:37]:
> On Fri, 19 Sep 2014, Nishanth Menon wrote:
> > On 08:37-20140919, Thomas Gleixner wrote:
> > > The other omap drivers using this have the same issue ... And of
> > > course they are subtly different.
> > >
> > > The uart one handles the actual device interrupt,
On Fri, 19 Sep 2014, Nishanth Menon wrote:
> On 08:37-20140919, Thomas Gleixner wrote:
> > The other omap drivers using this have the same issue ... And of
> > course they are subtly different.
> >
> > The uart one handles the actual device interrupt, which is violating
> > the general rule of pos
On 08:37-20140919, Thomas Gleixner wrote:
> On Thu, 18 Sep 2014, Nishanth Menon wrote:
> > On 17:57-20140918, Thomas Gleixner wrote:
> >
> > I suppose I can improve the commit message to elaborate this better?
> > Will that help?
>
> You also want to improve the comment in the empty handler.
OK.
On Thu, 18 Sep 2014, Nishanth Menon wrote:
> On 17:57-20140918, Thomas Gleixner wrote:
>
> I suppose I can improve the commit message to elaborate this better?
> Will that help?
You also want to improve the comment in the empty handler.
> >
> > > + */
> > > + return IRQ_NONE;
And it still doe
On 17:57-20140918, Thomas Gleixner wrote:
> On Thu, 18 Sep 2014, Nishanth Menon wrote:
> > +static irqreturn_t palmas_wake_irq(int irq, void *_palmas)
> > +{
> > + /*
> > +* Return Not handled so that interrupt is disabled.
>
> And how is that interrupt disabled by returning IRQ_NONE? You me
On Thu, 18 Sep 2014, Nishanth Menon wrote:
> +static irqreturn_t palmas_wake_irq(int irq, void *_palmas)
> +{
> + /*
> + * Return Not handled so that interrupt is disabled.
And how is that interrupt disabled by returning IRQ_NONE? You mean it
gets disabled after it got reraised 10 tim
With the recent pinctrl-single changes, omaps can treat wake-up events
from deeper power states as interrupts.
This is to handle the case where the system needs two interrupt
sources when SoC is in deep sleep(1 to exit from deep power mode such
as sleep, and other from the module handling the act
20 matches
Mail list logo
