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
19 matches
Mail list logo
