From: Samuel Holland <samuel@sholland.org> To: Maxime Ripard <maxime@cerno.tech> Cc: Thomas Gleixner <tglx@linutronix.de>, Marc Zyngier <maz@kernel.org>, Rob Herring <robh+dt@kernel.org>, Chen-Yu Tsai <wens@csie.org>, Jernej Skrabec <jernej.skrabec@siol.net>, Russell King <linux@armlinux.org.uk>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Ondrej Jirman <megous@megous.com>, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-sunxi@googlegroups.com Subject: Re: [PATCH v3 01/10] dt-bindings: irq: sun6i-r: Split the binding from sun7i-nmi Date: Fri, 8 Jan 2021 09:40:09 -0600 [thread overview] Message-ID: <e6ab1926-e69d-1e66-32d8-19870625ee17@sholland.org> (raw) In-Reply-To: <20210108094453.7uk5lj6j6gdmydiw@gilmour> On 1/8/21 3:44 AM, Maxime Ripard wrote: > Hi Samuel, > > Thanks a lot for working on this > > I'm fine with the rest of the work, but I have a couple of questions > > On Sun, Jan 03, 2021 at 04:30:52AM -0600, Samuel Holland wrote: >> The R_INTC in the A31 and newer sun8i/sun50i SoCs has additional >> functionality compared to the sun7i/sun9i NMI controller. Among other >> things, it multiplexes up to 128 interrupts corresponding to (and in >> parallel to) the first 128 GIC SPIs. This means the NMI is no longer the >> lowest-numbered interrupt, since it is SPI 32 or 96 (depending on SoC). >> >> To allow access to all multiplexed IRQs, the R_INTC requires a new >> binding where the interrupt number matches the GIC interrupt number. >> For simplicity, copy the three-cell GIC binding; this disambiguates >> interrupt 0 in the old binding (the NMI) from interrupt 0 in the new >> binding (SPI 0) by the number of cells. > > It's not really clear to me what the ambiguity is between the NMI and > the SPI 0 interrupt? Here's the ASCII art I will include in v4: NMI IRQ DIRECT IRQs MUXED IRQs bit 0 bits 1-18 bits 19-31 +---------+ +---------+ +---------+ +---------+ | NMI Pad | | IRQ d | | IRQ m | | IRQ m+7 | +---------+ +---------+ +---------+ +---------+ | | | | | | | | | | | |......| | +------V------+ +-------------+ | | | +--V------V--+ | | Invert/ | | Write | | | | | AND with | | | Edge Detect | | PENDING[0] | | | | | MUX[m/8] | | +-------------+ +-------------+ | | | +------------+ | | | | | | | | +--V-------V--+ +--V--+ | +--V--+ | +--V--+ | Set Reset| | GIC | | | GIC | | | GIC | | Latch | | SPI | | | SPI |... | ...| SPI | +-------------+ | N+d | | | m | | | m+7 | | | +-----+ | +-----+ | +-----+ | | | | +-------V-+ +-V-----------+ +---------V---+ +---------V----------+ | GIC SPI | | AND with | | AND with | | AND with | | N (=32) | | ENABLE[0] | | ENABLE[d] | | ENABLE[19+m/8] | +---------+ +-------------+ +-------------+ +--------------------+ | | | +------V------+ +------V------+ +---------V----------+ | Read | | Read | | Read | | PENDING[0] | | PENDING[d] | | PENDING[19+m/8] | +-------------+ +-------------+ +--------------------+ There are two overlapping ranges of IRQs supported by the controller, and so there are two different IRQs you could call "IRQ 0": - Bit 0 of PENDING/ENABLE/MASK, aka d==0, the NMI - This maps to bit 32 of the MUX register range (SPI 32) - This is what the old binding calls "IRQ 0" - Bit 0 of MUX, aka m==0, aka SPI 0, the UART0 IRQ - This maps to bit 19 of PENDING/ENABLE/MASK - This is what the new binding calls "IRQ 0" You can see this insertion in the middle of the MUX range when looking at the mask of implemented MUX bits in the A31 variant: 0xffffffff, 0xfff80000, <<< this gap here is for the 19 direct IRQs 0xffffffff, 0x0000000f, If you call the NMI "IRQ 0", then there is no way to specify the muxed IRQs. SPI 0 maps to bit 19, but so do SPI 1-7. So if I was to specify "IRQ 19", you wouldn't know which of those 8 muxed SPIs I am referring to. On the other hand, if you call the first muxed IRQ "IRQ 0", then there is an unambiguous number for every interrupt supported by this driver. > In general, it looks like switching to a 3-cell binding with the GIC SPI > value looks weird to me, since the GIC isn't the parent at all of these > interrupts. The GIC is *a* parent of all of these interrupts, and is *the* parent of the NMI. > If the ambiguity is that a stacked irqchip driver needs to have the same > interrupt number than the GIC, and that the 0 interrupt for the NMI > controller (used by the PMIC) and is actually the 32 (or 96) GIC > interrupt and thus breaks that requirement, can't we fix this in the > driver based on the compatible? No, while the NMI is direct "IRQ 0" at this irqchip, it is *also* muxed "IRQ 32" at this same irqchip. > Something like if the interrupt number is 0, with a A31 or newer > compatible, then add the proper offset in sun6i_r_intc_domain_alloc? If you translate 0 to 32, then you cannot represent muxed IRQ 0 (the UART0 IRQ) at all. > Maxime Cheers, Samuel
WARNING: multiple messages have this Message-ID (diff)
From: Samuel Holland <samuel@sholland.org> To: Maxime Ripard <maxime@cerno.tech> Cc: Ondrej Jirman <megous@megous.com>, devicetree@vger.kernel.org, Jernej Skrabec <jernej.skrabec@siol.net>, Marc Zyngier <maz@kernel.org>, linux-sunxi@googlegroups.com, Russell King <linux@armlinux.org.uk>, linux-kernel@vger.kernel.org, Chen-Yu Tsai <wens@csie.org>, Rob Herring <robh+dt@kernel.org>, Catalin Marinas <catalin.marinas@arm.com>, Thomas Gleixner <tglx@linutronix.de>, Will Deacon <will@kernel.org>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v3 01/10] dt-bindings: irq: sun6i-r: Split the binding from sun7i-nmi Date: Fri, 8 Jan 2021 09:40:09 -0600 [thread overview] Message-ID: <e6ab1926-e69d-1e66-32d8-19870625ee17@sholland.org> (raw) In-Reply-To: <20210108094453.7uk5lj6j6gdmydiw@gilmour> On 1/8/21 3:44 AM, Maxime Ripard wrote: > Hi Samuel, > > Thanks a lot for working on this > > I'm fine with the rest of the work, but I have a couple of questions > > On Sun, Jan 03, 2021 at 04:30:52AM -0600, Samuel Holland wrote: >> The R_INTC in the A31 and newer sun8i/sun50i SoCs has additional >> functionality compared to the sun7i/sun9i NMI controller. Among other >> things, it multiplexes up to 128 interrupts corresponding to (and in >> parallel to) the first 128 GIC SPIs. This means the NMI is no longer the >> lowest-numbered interrupt, since it is SPI 32 or 96 (depending on SoC). >> >> To allow access to all multiplexed IRQs, the R_INTC requires a new >> binding where the interrupt number matches the GIC interrupt number. >> For simplicity, copy the three-cell GIC binding; this disambiguates >> interrupt 0 in the old binding (the NMI) from interrupt 0 in the new >> binding (SPI 0) by the number of cells. > > It's not really clear to me what the ambiguity is between the NMI and > the SPI 0 interrupt? Here's the ASCII art I will include in v4: NMI IRQ DIRECT IRQs MUXED IRQs bit 0 bits 1-18 bits 19-31 +---------+ +---------+ +---------+ +---------+ | NMI Pad | | IRQ d | | IRQ m | | IRQ m+7 | +---------+ +---------+ +---------+ +---------+ | | | | | | | | | | | |......| | +------V------+ +-------------+ | | | +--V------V--+ | | Invert/ | | Write | | | | | AND with | | | Edge Detect | | PENDING[0] | | | | | MUX[m/8] | | +-------------+ +-------------+ | | | +------------+ | | | | | | | | +--V-------V--+ +--V--+ | +--V--+ | +--V--+ | Set Reset| | GIC | | | GIC | | | GIC | | Latch | | SPI | | | SPI |... | ...| SPI | +-------------+ | N+d | | | m | | | m+7 | | | +-----+ | +-----+ | +-----+ | | | | +-------V-+ +-V-----------+ +---------V---+ +---------V----------+ | GIC SPI | | AND with | | AND with | | AND with | | N (=32) | | ENABLE[0] | | ENABLE[d] | | ENABLE[19+m/8] | +---------+ +-------------+ +-------------+ +--------------------+ | | | +------V------+ +------V------+ +---------V----------+ | Read | | Read | | Read | | PENDING[0] | | PENDING[d] | | PENDING[19+m/8] | +-------------+ +-------------+ +--------------------+ There are two overlapping ranges of IRQs supported by the controller, and so there are two different IRQs you could call "IRQ 0": - Bit 0 of PENDING/ENABLE/MASK, aka d==0, the NMI - This maps to bit 32 of the MUX register range (SPI 32) - This is what the old binding calls "IRQ 0" - Bit 0 of MUX, aka m==0, aka SPI 0, the UART0 IRQ - This maps to bit 19 of PENDING/ENABLE/MASK - This is what the new binding calls "IRQ 0" You can see this insertion in the middle of the MUX range when looking at the mask of implemented MUX bits in the A31 variant: 0xffffffff, 0xfff80000, <<< this gap here is for the 19 direct IRQs 0xffffffff, 0x0000000f, If you call the NMI "IRQ 0", then there is no way to specify the muxed IRQs. SPI 0 maps to bit 19, but so do SPI 1-7. So if I was to specify "IRQ 19", you wouldn't know which of those 8 muxed SPIs I am referring to. On the other hand, if you call the first muxed IRQ "IRQ 0", then there is an unambiguous number for every interrupt supported by this driver. > In general, it looks like switching to a 3-cell binding with the GIC SPI > value looks weird to me, since the GIC isn't the parent at all of these > interrupts. The GIC is *a* parent of all of these interrupts, and is *the* parent of the NMI. > If the ambiguity is that a stacked irqchip driver needs to have the same > interrupt number than the GIC, and that the 0 interrupt for the NMI > controller (used by the PMIC) and is actually the 32 (or 96) GIC > interrupt and thus breaks that requirement, can't we fix this in the > driver based on the compatible? No, while the NMI is direct "IRQ 0" at this irqchip, it is *also* muxed "IRQ 32" at this same irqchip. > Something like if the interrupt number is 0, with a A31 or newer > compatible, then add the proper offset in sun6i_r_intc_domain_alloc? If you translate 0 to 32, then you cannot represent muxed IRQ 0 (the UART0 IRQ) at all. > Maxime Cheers, Samuel _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-01-08 15:40 UTC|newest] Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-03 10:30 [PATCH v3 00/10] sunxi: Support IRQ wakeup from deep sleep Samuel Holland 2021-01-03 10:30 ` Samuel Holland 2021-01-03 10:30 ` [PATCH v3 01/10] dt-bindings: irq: sun6i-r: Split the binding from sun7i-nmi Samuel Holland 2021-01-03 10:30 ` Samuel Holland 2021-01-08 9:44 ` Maxime Ripard 2021-01-08 9:44 ` Maxime Ripard 2021-01-08 15:40 ` Samuel Holland [this message] 2021-01-08 15:40 ` Samuel Holland 2021-01-11 22:29 ` Rob Herring 2021-01-11 22:29 ` Rob Herring 2021-01-03 10:30 ` [PATCH v3 02/10] dt-bindings: irq: sun6i-r: Add a compatible for the H3 Samuel Holland 2021-01-03 10:30 ` Samuel Holland 2021-01-11 22:29 ` Rob Herring 2021-01-11 22:29 ` Rob Herring 2021-01-03 10:30 ` [PATCH v3 03/10] irqchip/sun6i-r: Use a stacked irqchip driver Samuel Holland 2021-01-03 10:30 ` Samuel Holland 2021-01-03 11:27 ` Marc Zyngier 2021-01-03 11:27 ` Marc Zyngier 2021-01-03 12:08 ` Samuel Holland 2021-01-03 12:08 ` Samuel Holland 2021-01-03 13:10 ` Marc Zyngier 2021-01-03 13:10 ` Marc Zyngier 2021-01-04 3:46 ` Samuel Holland 2021-01-04 3:46 ` Samuel Holland 2021-01-04 10:03 ` Marc Zyngier 2021-01-04 10:03 ` Marc Zyngier 2021-01-03 10:30 ` [PATCH v3 04/10] irqchip/sun6i-r: Add wakeup support Samuel Holland 2021-01-03 10:30 ` Samuel Holland 2021-01-03 10:30 ` [PATCH v3 05/10] ARM: dts: sunxi: Rename nmi_intc to r_intc Samuel Holland 2021-01-03 10:30 ` Samuel Holland 2021-01-03 10:30 ` [PATCH v3 06/10] ARM: dts: sunxi: Use the new r_intc binding Samuel Holland 2021-01-03 10:30 ` Samuel Holland 2021-01-03 10:30 ` [PATCH v3 07/10] ARM: dts: sunxi: h3/h5: Add r_intc node Samuel Holland 2021-01-03 10:30 ` Samuel Holland 2021-01-03 10:30 ` [PATCH v3 08/10] ARM: dts: sunxi: Move wakeup-capable IRQs to r_intc Samuel Holland 2021-01-03 10:30 ` Samuel Holland 2021-01-03 10:31 ` [PATCH v3 09/10] arm64: dts: allwinner: Use the new r_intc binding Samuel Holland 2021-01-03 10:31 ` Samuel Holland 2021-01-03 10:31 ` [PATCH v3 10/10] arm64: dts: allwinner: Move wakeup-capable IRQs to r_intc Samuel Holland 2021-01-03 10:31 ` Samuel Holland 2021-01-03 12:16 ` [PATCH v3 00/10] sunxi: Support IRQ wakeup from deep sleep Marc Zyngier 2021-01-03 12:16 ` Marc Zyngier 2021-01-03 12:43 ` Samuel Holland 2021-01-03 12:43 ` Samuel Holland
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=e6ab1926-e69d-1e66-32d8-19870625ee17@sholland.org \ --to=samuel@sholland.org \ --cc=catalin.marinas@arm.com \ --cc=devicetree@vger.kernel.org \ --cc=jernej.skrabec@siol.net \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-sunxi@googlegroups.com \ --cc=linux@armlinux.org.uk \ --cc=maxime@cerno.tech \ --cc=maz@kernel.org \ --cc=megous@megous.com \ --cc=robh+dt@kernel.org \ --cc=tglx@linutronix.de \ --cc=wens@csie.org \ --cc=will@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.