From: Marc Zyngier <maz@kernel.org> To: Samuel Holland <samuel@sholland.org> Cc: Thomas Gleixner <tglx@linutronix.de>, Rob Herring <robh+dt@kernel.org>, Maxime Ripard <mripard@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 Subject: Re: [PATCH v3 03/10] irqchip/sun6i-r: Use a stacked irqchip driver Date: Mon, 04 Jan 2021 10:03:47 +0000 [thread overview] Message-ID: <a9359739794dc803723c9a6750a96474@kernel.org> (raw) In-Reply-To: <8c1eaddd-577b-9c2a-aa6a-9ee716178d4a@sholland.org> On 2021-01-04 03:46, Samuel Holland wrote: > On 1/3/21 7:10 AM, Marc Zyngier wrote: >> On Sun, 03 Jan 2021 12:08:43 +0000, >> Samuel Holland <samuel@sholland.org> wrote: >>> >>> On 1/3/21 5:27 AM, Marc Zyngier wrote: [...] >>> For edge interrupts, don't you want to ack as early as possible, >>> before the handler clears the source of the interrupt? That way if a >>> second interrupt comes in while you're handling the first one, you >>> don't ack the second one without handling it? >> >> It completely depends on what this block does. If, as I expect, it >> latches the interrupt, then it needs clearing after the GIC has acked >> the incoming interrupt. > > Yes, there is an internal S/R latch. > - For edge interrupts, the latch is set once for each pulse. > - For level interrupts, it gets set continuously as long as the > pin is high/low. > - Writing a "1" to bit 0 of PENDING resets the latch. > - The output of the latch goes to the GIC. > >>>> It also begs the question: why would you want to clear the signal to >>>> the GIC on mask (or unmask)? The expectations are that a pending >>>> interrupt is preserved across a mask/unmask sequence. >>> >>> I hadn't thought about anything masking the IRQ outside of the >>> handler; but you're right, this breaks that case. I'm trying to work >>> within the constraints of stacking the GIC driver, which assumes >>> handle_fasteoi_irq, so it sounds like I should switch back to >>> handle_fasteoi_ack_irq and use .irq_ack. Or based on your previous >>> paragraph, maybe I'm missing some other consideration? >> >> handle_fasteoi_ack_irq() sounds like a good match for edge >> interrupts. Do you actually need to do anything for level signals? If >> you do, piggybacking on .irq_eoi would do the trick. > > For level interrupts, I have to reset the latch (see above) after the > source of > the interrupt is cleared. Right, so that is definitely to be done in .irq_eoi, at least in the non-threaded case (as it doesn't involve masking/unmasking). > That was the bug with v2: I set IRQ_EOI_THREADED so .irq_eoi would run > after the > thread. But with GICv2 EOImode==0, that blocked other interrupts from > being > received during the IRQ thread. Which is why I moved it to .irq_unmask > and > removed the flag: so .irq_eoi runs at the end of the hardirq > (unblocking further > interrupts at the GIC), and .irq_unmask resets the latch at the end of > the thread. > > With the flag removed, but still clearing the latch in .irq_eoi, every > edge IRQ edge? Didn't you mean level here? Edge interrupts really should clear the latch in .irq_ack. > was followed by a second, spurious IRQ after the thread finished. > > Does that make sense? It does. It is a bit of a kludge, but hey, silly HW (if only this could be turned into a bypass, it'd all be simpler). To sum it up, this is what I'd expect to see: For edge interrupts: - clear latch in .irq_ack and .irq_set_irqchip_state(PENDING) - interrupt flow set to fasteoi_ack For level interrupts - clear latch in .irq_eoi (non-threaded) and .irq_unmask (threaded) - interrupt flow set to fasteoi (though leaving to the _ack version should not hurt). Thanks, M. -- Jazz is not dead. It just smells funny...
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org> To: Samuel Holland <samuel@sholland.org> Cc: Ondrej Jirman <megous@megous.com>, devicetree@vger.kernel.org, Jernej Skrabec <jernej.skrabec@siol.net>, Catalin Marinas <catalin.marinas@arm.com>, Russell King <linux@armlinux.org.uk>, Maxime Ripard <mripard@kernel.org>, linux-kernel@vger.kernel.org, Chen-Yu Tsai <wens@csie.org>, Rob Herring <robh+dt@kernel.org>, Thomas Gleixner <tglx@linutronix.de>, Will Deacon <will@kernel.org>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v3 03/10] irqchip/sun6i-r: Use a stacked irqchip driver Date: Mon, 04 Jan 2021 10:03:47 +0000 [thread overview] Message-ID: <a9359739794dc803723c9a6750a96474@kernel.org> (raw) In-Reply-To: <8c1eaddd-577b-9c2a-aa6a-9ee716178d4a@sholland.org> On 2021-01-04 03:46, Samuel Holland wrote: > On 1/3/21 7:10 AM, Marc Zyngier wrote: >> On Sun, 03 Jan 2021 12:08:43 +0000, >> Samuel Holland <samuel@sholland.org> wrote: >>> >>> On 1/3/21 5:27 AM, Marc Zyngier wrote: [...] >>> For edge interrupts, don't you want to ack as early as possible, >>> before the handler clears the source of the interrupt? That way if a >>> second interrupt comes in while you're handling the first one, you >>> don't ack the second one without handling it? >> >> It completely depends on what this block does. If, as I expect, it >> latches the interrupt, then it needs clearing after the GIC has acked >> the incoming interrupt. > > Yes, there is an internal S/R latch. > - For edge interrupts, the latch is set once for each pulse. > - For level interrupts, it gets set continuously as long as the > pin is high/low. > - Writing a "1" to bit 0 of PENDING resets the latch. > - The output of the latch goes to the GIC. > >>>> It also begs the question: why would you want to clear the signal to >>>> the GIC on mask (or unmask)? The expectations are that a pending >>>> interrupt is preserved across a mask/unmask sequence. >>> >>> I hadn't thought about anything masking the IRQ outside of the >>> handler; but you're right, this breaks that case. I'm trying to work >>> within the constraints of stacking the GIC driver, which assumes >>> handle_fasteoi_irq, so it sounds like I should switch back to >>> handle_fasteoi_ack_irq and use .irq_ack. Or based on your previous >>> paragraph, maybe I'm missing some other consideration? >> >> handle_fasteoi_ack_irq() sounds like a good match for edge >> interrupts. Do you actually need to do anything for level signals? If >> you do, piggybacking on .irq_eoi would do the trick. > > For level interrupts, I have to reset the latch (see above) after the > source of > the interrupt is cleared. Right, so that is definitely to be done in .irq_eoi, at least in the non-threaded case (as it doesn't involve masking/unmasking). > That was the bug with v2: I set IRQ_EOI_THREADED so .irq_eoi would run > after the > thread. But with GICv2 EOImode==0, that blocked other interrupts from > being > received during the IRQ thread. Which is why I moved it to .irq_unmask > and > removed the flag: so .irq_eoi runs at the end of the hardirq > (unblocking further > interrupts at the GIC), and .irq_unmask resets the latch at the end of > the thread. > > With the flag removed, but still clearing the latch in .irq_eoi, every > edge IRQ edge? Didn't you mean level here? Edge interrupts really should clear the latch in .irq_ack. > was followed by a second, spurious IRQ after the thread finished. > > Does that make sense? It does. It is a bit of a kludge, but hey, silly HW (if only this could be turned into a bypass, it'd all be simpler). To sum it up, this is what I'd expect to see: For edge interrupts: - clear latch in .irq_ack and .irq_set_irqchip_state(PENDING) - interrupt flow set to fasteoi_ack For level interrupts - clear latch in .irq_eoi (non-threaded) and .irq_unmask (threaded) - interrupt flow set to fasteoi (though leaving to the _ack version should not hurt). Thanks, M. -- Jazz is not dead. It just smells funny... _______________________________________________ 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-04 10:04 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 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 [this message] 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=a9359739794dc803723c9a6750a96474@kernel.org \ --to=maz@kernel.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@armlinux.org.uk \ --cc=megous@megous.com \ --cc=mripard@kernel.org \ --cc=robh+dt@kernel.org \ --cc=samuel@sholland.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.