Re: [PATCH v4 3/5] irqchip: Add DT binding doc for the virtual irq demuxer chip

From: Boris Brezillon
Date: Fri Feb 20 2015 - 09:53:58 EST

Hi Mark,

On Fri, 20 Feb 2015 14:22:08 +0000
Mark Rutland <mark.rutland@xxxxxxx> wrote:

> Hi Boris,
> On Wed, Feb 11, 2015 at 04:38:23PM +0000, Boris Brezillon wrote:
> [...]
> > For the list of impacted drivers, you can have a look at this series [1]
> > (patches 2 to 5), and I'll take care of the testing part once every one
> > has agreed on the solution ;-).
> >
> > [1]
> Looking at those:
> * The pmc looks like it could be a valid use of the new flag. It also
> seems to function as an irqchip.
> Do any of its child IRQs need to be handled during the suspend-resume
> cycle? If so using IRQF_NO_SUSPEND would seem to be valid.

No they don't, they are used for clock activation only, and thus should
be disabled on suspend.

> * atmel_serial seems to be intended to be used as a wakeup device (given
> it calls device_set_wakeup_enable). Therefore it needs to call
> enable_irq_wake, and when it does so it can share an IRQ with other
> interrupts, just not IRQF_NO_SUSPEND interrupts.

I'll have a look, but AFAIR serial core already taking care of that.

> None of the approaches thus far can fix the fundamental mismatch
> between wakeup interrupts and IRQF_NO_SUSPEND interrupts.
> * Similarly, rtc-at91rm9200 and rtc-at91sam9 are intended to be used as
> wakeup devices. They call enable_irq_wake (though don't bother
> checking the return value). They can share an IRQ with other
> interrupts, just not IRQF_NO_SUSPEND interrupts.


> * at91sam9_wdt seems to be fundamentally incompatible with suspend. If
> the watchdog cannot be disabled, and you need to handle it during
> suspend, then it needs to be a wakeup interrupt, not an
> IRQF_NO_SUSPEND interrupt.

You forgot the PIT timer, which is the one in cause here (no other
drivers are specifying this IRQF_NO_SUSPEND flag), and, as you already
know, a timer sets the IRQF_NO_SUSPEND flag.

> As far as I can see, the flag or virtual irqchip approaches only help
> the PMC case, and even then might not be necessary. All the others seem
> to be relying on guarantees the genirq layer don't provide, and fixing
> that would mean moving them further from IRQF_NO_SUSPEND.

I don't know what you're trying to prove here, but I never said my goal
was to set IRQF_NO_SUSPEND flags on existing at91 drivers ?
The problem here, is that all those IPs are sharing the irq line with a
timer which sets IRQF_NO_SUSPEND.

I just want to be able to share an irq line with a timer and other
devices that do not set IRQF_NO_SUSPEND.
Could we focus on that ?

Best Regards,


Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at