[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200608084853.wr6eca5nt772p5h7@gilmour.lan>
Date: Mon, 8 Jun 2020 10:48:53 +0200
From: Maxime Ripard <maxime@...no.tech>
To: Samuel Holland <samuel@...lland.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Jason Cooper <jason@...edaemon.net>,
Marc Zyngier <maz@...nel.org>,
Rob Herring <robh+dt@...nel.org>, Chen-Yu Tsai <wens@...e.org>,
Russell King <linux@...linux.org.uk>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>, devicetree@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-sunxi@...glegroups.com
Subject: Re: [PATCH v2 1/9] irqchip/sun6i-r: Use a stacked irqchip driver
On Sun, May 24, 2020 at 11:12:54PM -0500, Samuel Holland wrote:
> The R_INTC in the A31 and newer sun8i/sun50i SoCs is more similar to the
> original sun4i interrupt controller than the sun7i/sun9i NMI controller.
> It is used for two distinct purposes:
> 1) To control the trigger, latch, and mask for the NMI input pin
> 2) To provide the interrupt input for the ARISC coprocessor
>
> As this interrupt controller is not documented, information about it
> comes from vendor-provided ARISC firmware and from experimentation.
>
> Like the original sun4i interrupt controller, it has:
> - A VECTOR_REG at 0x00 (configurable via the BASE_ADDR_REG at 0x04)
> - A NMI_CTRL_REG, PENDING_REG, and ENABLE_REG as used by both the
> sun4i and sunxi-nmi drivers
> - A MASK_REG at 0x50
> - A RESP_REG at 0x60
>
> Differences from the sun4i interrupt controller appear to be:
> - It is only known to have one register of each kind (max 32 inputs)
> - There is no FIQ-related logic
> - There is no interrupt priority logic
>
> In order to fulfill its two purposes, this hardware block combines two
> types of IRQs. First, the NMI pin is routed to the "IRQ 0" input on this
> chip, with a trigger type controlled by the NMI_CTRL_REG. The "IRQ 0
> pending" output from this chip, if enabled, is then routed to a SPI IRQ
> input on the GIC, as IRQ_TYPE_LEVEL_HIGH. In other words, bit 0 of
> ENABLE_REG *does* affect the NMI IRQ seen at the GIC.
>
> The NMI is then followed by a contiguous block of (at least) 15 IRQ
> inputs that are connected in parallel to both R_INTC and the GIC. Or
> in other words, the other bits of ENABLE_REG *do not* affect the IRQs
> seen at the GIC.
>
> Finally, the global "IRQ pending" output from R_INTC, after being masked
> by MASK_REG and RESP_REG, is connected to the "external interrupt" input
> of the ARISC CPU (an OR1200). This path is not relevant to Linux.
>
> Because of the 1:1 correspondence between R_INTC and GIC inputs, this is
> a perfect scenario for using a stacked irqchip driver. We want to hook
> into enabling/disabling IRQs to add more features to the GIC
> (specifically to allow masking the NMI and setting its trigger type),
> but we don't need to actually handle the IRQ in this driver.
>
> And since R_INTC is in the always-on power domain, and its output is
> connected directly in to the power management coprocessor, a stacked
> irqchip driver provides a simple way to add wakeup support to this set
> of IRQs. That is a future patch; for now, just the NMI is moved over.
>
> This driver keeps the same DT binding as the existing driver. The
> "interrupt" property of the R_INTC node is used to determine 1) the
> offset between GIC and R_INTC hwirq numbers and 2) the type of trigger
> between the R_INTC "IRQ 0 pending" output and the GIC NMI input.
>
> This commit mostly reverts commit 173bda53b340 ("irqchip/sunxi-nmi:
> Support sun6i-a31-r-intc compatible").
>
> Signed-off-by: Samuel Holland <samuel@...lland.org>
As usual, thanks for that commit log (and the experiments you did to
write it in the first place).
Acked-by: Maxime Ripard <mripard@...nel.org>
Maxime
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists