[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1422032971-14139-1-git-send-email-boris.brezillon@free-electrons.com>
Date: Fri, 23 Jan 2015 18:09:26 +0100
From: Boris Brezillon <boris.brezillon@...e-electrons.com>
To: Thomas Gleixner <tglx@...utronix.de>,
Jason Cooper <jason@...edaemon.net>,
Nicolas Ferre <nicolas.ferre@...el.com>,
Jean-Christophe Plagniol-Villard <plagnioj@...osoft.com>,
Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
Rob Herring <robh+dt@...nel.org>
Cc: Pawel Moll <pawel.moll@....com>,
Mark Rutland <mark.rutland@....com>,
Ian Campbell <ijc+devicetree@...lion.org.uk>,
Kumar Gala <galak@...eaurora.org>, devicetree@...r.kernel.org,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
Boris Brezillon <boris.brezillon@...e-electrons.com>
Subject: [PATCH v3 0/5] ARM: at91: fix irq_pm_install_action WARNING
Commit cab303be91dc47942bc25de33dc1140123540800 [1] introduced a WARN_ON
test which triggers a WARNING backtrace on at91 platforms.
While this WARN_ON is absolutely necessary to warn users that they should
not mix request with and without IRQF_NO_SUSPEND flags on shared IRQs,
there is no easy way to solve this issue on at91 platforms.
The main reason is that the init timer is often using a shared irq line
and thus request this irq with IRQF_NO_SUSPEND flag set, while other
peripherals request the same irq line without this flag.
As suggested by Thomas, the first 3 patches of this series add a dumb
demultiplexer irqchip implementation.
This demuxer registers to a source interrupt and then forwards all received
interrupts to its children (it they are enabled).
The last two patches rework at91 DTs and config to make use of this dumb
demuxer implementation.
Rob, I know you were not in favor of exposing this in the DT but we really
need to quickly a solution: more and more people complain about this warning.
If you see a better way to handle this case please share it.
Best Regards,
Boris
Changes since v2:
- removed unneeded dumb demux flags passed to irq_alloc_dumb_demux_chip
- set nested lockdep class for all requested irqs
- add some explanation to the DT binding doc
- change the compatible string to clearly show that this chip is purely
virtual
- added dumb demuxer to all at91 impacted SoCs
Changes since v1:
- went for an dumb irq demuxer approach instead of trying to fix the
current shared irq code
Boris Brezillon (5):
genirq: Authorize chained handlers to remain disabled when initialized
irqchip: add dumb demultiplexer implementation
irqchip: Add DT binding doc for dumb demuxer chips
ARM: at91/dt: select DUMB_IRQ_DEMUX for all at91 SoCs
ARM: at91/dt: define a dumb irq demultiplexer chip connected on irq1
.../bindings/interrupt-controller/dumb-demux.txt | 41 ++++++
arch/arm/boot/dts/at91rm9200.dtsi | 20 ++-
arch/arm/boot/dts/at91sam9260.dtsi | 26 +++-
arch/arm/boot/dts/at91sam9261.dtsi | 26 +++-
arch/arm/boot/dts/at91sam9263.dtsi | 29 ++++-
arch/arm/boot/dts/at91sam9g45.dtsi | 29 ++++-
arch/arm/boot/dts/at91sam9n12.dtsi | 25 +++-
arch/arm/boot/dts/at91sam9rl.dtsi | 29 ++++-
arch/arm/boot/dts/at91sam9x5.dtsi | 26 +++-
arch/arm/mach-at91/Kconfig | 2 +
drivers/irqchip/Kconfig | 4 +
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-dumb-demux.c | 72 +++++++++++
include/linux/irq.h | 64 +++++++++-
include/linux/irqdomain.h | 1 +
kernel/irq/Kconfig | 5 +
kernel/irq/Makefile | 1 +
kernel/irq/chip.c | 53 +++++++-
kernel/irq/dumb-demux-chip.c | 140 +++++++++++++++++++++
kernel/irq/handle.c | 31 ++++-
kernel/irq/internals.h | 3 +
kernel/irq/irqdomain.c | 2 +-
kernel/irq/msi.c | 3 +-
23 files changed, 580 insertions(+), 53 deletions(-)
create mode 100644 Documentation/devicetree/bindings/interrupt-controller/dumb-demux.txt
create mode 100644 drivers/irqchip/irq-dumb-demux.c
create mode 100644 kernel/irq/dumb-demux-chip.c
--
1.9.1
--
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