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:
* 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
> > + */
> >
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
Hi,
On Thu, Nov 13, 2014 at 09:40:31AM -0800, Tony Lindgren wrote:
[snip]
From: Tony Lindgren t...@atomide.com
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
* Felipe Balbi ba...@ti.com [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
+ */
On Fri, Nov 14, 2014 at 09:08:17AM -0800, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [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:
* 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?
* 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
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,
> > +
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 Gleixner t...@linutronix.de [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
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?
* Thomas Gleixner t...@linutronix.de [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
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
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 t...@atomide.com [141001 20:45]:
Hi Thomas,
* Thomas Gleixner t...@linutronix.de [140919 12:47]:
The wakeup handler is supposed to bring the thing out of
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
Hi Thomas,
* Thomas Gleixner t...@linutronix.de [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
* 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
>
>
* Thomas Gleixner t...@linutronix.de [140919 19:08]:
On Fri, 19 Sep 2014, Tony Lindgren wrote:
* Thomas Gleixner t...@linutronix.de [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
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
* 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
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
* 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
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
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
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 does not
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. will do
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 possible
* Thomas Gleixner t...@linutronix.de [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
On Fri, 19 Sep 2014, Tony Lindgren wrote:
* Thomas Gleixner t...@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.
* Thomas Gleixner t...@linutronix.de [140919 12:47]:
On Fri, 19 Sep 2014, Tony Lindgren wrote:
* Thomas Gleixner t...@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.
On Fri, 19 Sep 2014, Tony Lindgren wrote:
* Thomas Gleixner t...@linutronix.de [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
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
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
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
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 times
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 mean it
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
40 matches
Mail list logo
