[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150226090958.6bb80e76@bbrezillon>
Date: Thu, 26 Feb 2015 09:09:58 +0100
From: Boris Brezillon <boris.brezillon@...e-electrons.com>
To: "Rafael J. Wysocki" <rjw@...ysocki.net>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Jason Cooper <jason@...edaemon.net>,
Peter Zijlstra <peterz@...radead.org>,
Mark Rutland <mark.rutland@....com>,
linux-kernel@...r.kernel.org,
Nicolas Ferre <nicolas.ferre@...el.com>,
Jean-Christophe Plagniol-Villard <plagnioj@...osoft.com>,
Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC PATCH 2/3] genirq: add helper functions to deal with
wakeup on shared IRQF_NO_SUSPEND IRQs
On Wed, 25 Feb 2015 23:03:14 +0100
"Rafael J. Wysocki" <rjw@...ysocki.net> wrote:
> On Tuesday, February 24, 2015 10:56:01 AM Boris Brezillon wrote:
> > Add two helper functions to help drivers that are sharing IRQs with
> > timer devices (or other devices setting the IRQF_NO_SUSPEND flag) deal
> > with system wakeup and state detection.
> >
> > Such drivers should expect their IRQ handler to be called in 2 different
> > contexts:
> > 1/ the system is resumed and the handler should act normally
> > 2/ the system is suspended and the handler should wake it up, and
> > potentially save the received events so that they could be taken care
> > of when the resume callback is called
> >
> > irq_is_wakeup_armed provides mean to test the current state (true means
> > the system is suspended).
> >
> > irq_pm_force_wakeup provides mean to force a system wakeup.
> >
> > Signed-off-by: Boris Brezillon <boris.brezillon@...e-electrons.com>
> > ---
> > include/linux/interrupt.h | 3 +++
> > kernel/irq/manage.c | 16 ++++++++++++++++
> > kernel/irq/pm.c | 6 ++++++
> > 3 files changed, 25 insertions(+)
> >
> > diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
> > index d9b05b5..052a3b2 100644
> > --- a/include/linux/interrupt.h
> > +++ b/include/linux/interrupt.h
> > @@ -356,6 +356,9 @@ static inline int disable_irq_wake(unsigned int irq)
> > return irq_set_irq_wake(irq, 0);
> > }
> >
> > +bool irq_is_wakeup_armed(unsigned int irq);
> > +
> > +void irq_pm_force_wakeup(void);
> >
> > #ifdef CONFIG_IRQ_FORCED_THREADING
> > extern bool force_irqthreads;
> > diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
> > index 196a06f..5424be0 100644
> > --- a/kernel/irq/manage.c
> > +++ b/kernel/irq/manage.c
> > @@ -551,6 +551,22 @@ int irq_set_irq_wake(unsigned int irq, unsigned int on)
> > }
> > EXPORT_SYMBOL(irq_set_irq_wake);
> >
> > +bool irq_is_wakeup_armed(unsigned int irq)
> > +{
> > + unsigned long flags;
> > + struct irq_desc *desc = irq_get_desc_buslock(irq, &flags, IRQ_GET_DESC_CHECK_GLOBAL);
> > + bool ret;
> > +
> > + if (!desc)
> > + return false;
> > +
> > + ret = irqd_is_wakeup_armed(&desc->irq_data);
> > +
> > + irq_put_desc_busunlock(desc, flags);
> > + return ret;
> > +}
> > +EXPORT_SYMBOL(irq_is_wakeup_armed);
>
> Ugly that is ...
Yes, I'm not proud of it, but I wasn't sure when the handler was
supposed to start acting as a 'suspended' handler, and I thought
testing for this WAKEUP_ARMED bit was safer.
Anyway, as you pointed out in your previous answer, this bit is not set
when the IRQ line is not suspended, so this function is pretty much
useless.
>
> > +
> > /*
> > * Internal function that tells the architecture code whether a
> > * particular irq has been exclusively allocated or is available
> > diff --git a/kernel/irq/pm.c b/kernel/irq/pm.c
> > index 1743162..1110a37 100644
> > --- a/kernel/irq/pm.c
> > +++ b/kernel/irq/pm.c
> > @@ -28,6 +28,12 @@ bool irq_pm_check_wakeup(struct irq_desc *desc)
> > return false;
> > }
> >
> > +void irq_pm_force_wakeup(void)
> > +{
> > + pm_system_wakeup();
> > +}
> > +EXPORT_SYMBOL_GPL(irq_pm_force_wakeup);
>
> Why don't you export pm_system_wakeup() instead and use it directly?
Yep, I wasn't sure if pm_system_wakeup was reserved for core kernel
parts.
I don't have any concern exporting pm_system_wakeup instead.
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists