linux-kernel - [RFC PATCH V2 0/8] Add support for Tegra210 AGIC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <1450349309-8107-1-git-send-email-jonathanh@nvidia.com>
Date:	Thu, 17 Dec 2015 10:48:21 +0000
From:	Jon Hunter <jonathanh@...dia.com>
To:	Thomas Gleixner <tglx@...utronix.de>,
	Jason Cooper <jason@...edaemon.net>,
	Marc Zyngier <marc.zyngier@....com>,
	Jiang Liu <jiang.liu@...ux.intel.com>,
	Stephen Warren <swarren@...dotorg.org>,
	Thierry Reding <thierry.reding@...il.com>
CC:	Kevin Hilman <khilman@...nel.org>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Grygorii Strashko <grygorii.strashko@...com>,
	Lars-Peter Clausen <lars@...afoo.de>,
	Linus Walleij <linus.walleij@...aro.org>,
	Soren Brinkmann <soren.brinkmann@...inx.com>,
	linux-kernel@...r.kernel.org, <linux-tegra@...r.kernel.org>,
	Jon Hunter <jonathanh@...dia.com>
Subject: [RFC PATCH V2 0/8] Add support for Tegra210 AGIC

The Tegra210 AGIC interrupt controller is a 2nd level interrupt controller
located in a separate power domain to the main GIC interrupt controller.
It can route interrupts to the main CPU cluster or an Audio DSP slave.

Ideally we would like to re-use the existing ARM GIC driver because the
AGIC is a GIC-400. However, in order to do so this requires a few
significant changes to the exisiting GIC driver for power management
reasons.

The purpose of this RFC-V2 is to get some feedback on the approach and see
if we can support the AGIC in this way or if a separate driver is
warranted for this device.

Please note that this RFC does not address the issue of interrupt routing.
Ideally I was thinking that having a mechanism/API to migrate an interrupt
from the CPU cluster to the DSP would make sense, however, I don't believe
this is supported today in the kernel. Would such an approach be acceptable
or if not, is there a better way to handle this?

Changes from V1:
- Prevent IRQ mapping from setting the IRQ type and only program the
  type when allocating the IRQ.
- Resolved some __init section conflicts found with V1 series.

Jon Hunter (8):
  irqdomain: Ensure type settings match for an existing mapping
  irqdomain: Don't set type when mapping an IRQ
  genirq: Add runtime power management support for IRQ chips
  irqchip/gic: Don't initialise chip if mapping IO space fails
  irqchip/gic: Return an error if GIC initialisation fails
  irqchip/gic: Assign irqchip dynamically
  irqchip/gic: Prepare for adding platform driver
  irqchip/gic: Add support for tegra AGIC interrupt controller

 drivers/irqchip/irq-gic-common.c |   4 +-
 drivers/irqchip/irq-gic.c        | 473 ++++++++++++++++++++++++++++-----------
 include/linux/irq.h              |   4 +
 kernel/irq/internals.h           |  24 ++
 kernel/irq/irqdomain.c           |  76 +++++--
 kernel/irq/manage.c              |  14 ++
 6 files changed, 447 insertions(+), 148 deletions(-)

-- 
2.1.4

--
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/