From: Guo Ren <guoren@kernel.org> To: Samuel Holland <samuel@sholland.org> Cc: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>, Prabhakar <prabhakar.csengg@gmail.com>, Marc Zyngier <maz@kernel.org>, Sagar Kadam <sagar.kadam@sifive.com>, Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, linux-renesas-soc@vger.kernel.org, Geert Uytterhoeven <geert+renesas@glider.be>, Thomas Gleixner <tglx@linutronix.de>, Biju Das <biju.das.jz@bp.renesas.com>, Albert Ou <aou@eecs.berkeley.edu>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Rob Herring <robh+dt@kernel.org>, devicetree <devicetree@vger.kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, linux-riscv <linux-riscv@lists.infradead.org> Subject: Re: [PATCH v1 1/3] dt-bindings: interrupt-controller: Require trigger type for T-HEAD PLIC Date: Tue, 28 Jun 2022 11:04:22 +0800 [thread overview] Message-ID: <CAJF2gTR5Zb4TZbomVLbJdHG=JYrM9UkS4hxGeShXu0eu+SqpjQ@mail.gmail.com> (raw) In-Reply-To: <ab5b4722-8219-ab1c-e9d8-2c00e52040da@sholland.org> On Mon, Jun 27, 2022 at 10:14 PM Samuel Holland <samuel@sholland.org> wrote: > > On 6/27/22 2:40 AM, Guo Ren wrote: > > On Mon, Jun 27, 2022 at 1:13 PM Samuel Holland <samuel@sholland.org> wrote: > >> > >> The RISC-V PLIC specification unfortunately allows PLIC implementations > >> to ignore edges seen while an edge-triggered interrupt is being handled: > >> > >> Depending on the design of the device and the interrupt handler, > >> in between sending an interrupt request and receiving notice of its > >> handler’s completion, the gateway might either ignore additional > >> matching edges or increment a counter of pending interrupts. > >> > >> For PLICs with that misfeature, software needs to know the trigger type > >> of each interrupt. This allows it to work around the issue by completing > >> edge-triggered interrupts before handling them. Such a workaround is > >> required to avoid missing any edges. > >> > >> The T-HEAD C9xx PLIC is an example of a PLIC with this behavior. > > Actually, C9xx support pulse signals which configed by > > pad_plic_int_cfg_x for SoC vendor: > > > > https://github.com/T-head-Semi/openc906/blob/main/C906_RTL_FACTORY/gen_rtl/plic/rtl/plic_int_kid.v > > 104: assign int_new_pending = pad_plic_int_cfg_x ? int_pulse > > 105: > > : level_int_pending; > > > > They could put pad_plic_int_cfg_x into the SoC software config > > registers region or bind them to constant values. > > The issue here is the "!int_active" condition for int_new_set_pending, > regardless of that configuration input. > > For interrupt sources that send pulses, those pulses will be lost if they are > received while int_active is true. So the driver has to make sure int_active is > false _before_ servicing an interrupt, or it may miss the next one. This means > the driver needs to know which interrupt _sources_ send pulses and which ones > assert levels. You are right, in plus mode, we can't receive any interrupt between claim & complete, then the irq could be lost. I think the design follows the sentence written by PLIC spec: https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc If the global interrupt source was edge-triggered, the gateway will convert the first matching signal edge into an interrupt request. Depending on the design of the device and the interrupt handler, in between sending an interrupt request and receiving notice of its handler’s completion, the gateway might either **ignore additional matching edges** or increment a counter of pending interrupts. Also, the hardware could easily support the feature, but the engineer follows the first choice and disable the useful function. -_*! > > For level interrupts, pad_plic_int_cfg_x had better be 0, but that is a > hardware/firmware configuration concern. The driver should not have to care > about that. > > (On the Allwinner D1, those inputs are memory mapped, which was the reason for > the stacked interrupt controller mentioned in my other reply. But while > pad_plic_int_cfg_x == 1 only works with edge interrupts, the pad_plic_int_cfg_x > == 0 choice works with either kind of interrupt source, so the stacked driver is > not really needed.) > > Regards, > Samuel -- Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/
WARNING: multiple messages have this Message-ID (diff)
From: Guo Ren <guoren@kernel.org> To: Samuel Holland <samuel@sholland.org> Cc: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>, Prabhakar <prabhakar.csengg@gmail.com>, Marc Zyngier <maz@kernel.org>, Sagar Kadam <sagar.kadam@sifive.com>, Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, linux-renesas-soc@vger.kernel.org, Geert Uytterhoeven <geert+renesas@glider.be>, Thomas Gleixner <tglx@linutronix.de>, Biju Das <biju.das.jz@bp.renesas.com>, Albert Ou <aou@eecs.berkeley.edu>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Rob Herring <robh+dt@kernel.org>, devicetree <devicetree@vger.kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, linux-riscv <linux-riscv@lists.infradead.org> Subject: Re: [PATCH v1 1/3] dt-bindings: interrupt-controller: Require trigger type for T-HEAD PLIC Date: Tue, 28 Jun 2022 11:04:22 +0800 [thread overview] Message-ID: <CAJF2gTR5Zb4TZbomVLbJdHG=JYrM9UkS4hxGeShXu0eu+SqpjQ@mail.gmail.com> (raw) In-Reply-To: <ab5b4722-8219-ab1c-e9d8-2c00e52040da@sholland.org> On Mon, Jun 27, 2022 at 10:14 PM Samuel Holland <samuel@sholland.org> wrote: > > On 6/27/22 2:40 AM, Guo Ren wrote: > > On Mon, Jun 27, 2022 at 1:13 PM Samuel Holland <samuel@sholland.org> wrote: > >> > >> The RISC-V PLIC specification unfortunately allows PLIC implementations > >> to ignore edges seen while an edge-triggered interrupt is being handled: > >> > >> Depending on the design of the device and the interrupt handler, > >> in between sending an interrupt request and receiving notice of its > >> handler’s completion, the gateway might either ignore additional > >> matching edges or increment a counter of pending interrupts. > >> > >> For PLICs with that misfeature, software needs to know the trigger type > >> of each interrupt. This allows it to work around the issue by completing > >> edge-triggered interrupts before handling them. Such a workaround is > >> required to avoid missing any edges. > >> > >> The T-HEAD C9xx PLIC is an example of a PLIC with this behavior. > > Actually, C9xx support pulse signals which configed by > > pad_plic_int_cfg_x for SoC vendor: > > > > https://github.com/T-head-Semi/openc906/blob/main/C906_RTL_FACTORY/gen_rtl/plic/rtl/plic_int_kid.v > > 104: assign int_new_pending = pad_plic_int_cfg_x ? int_pulse > > 105: > > : level_int_pending; > > > > They could put pad_plic_int_cfg_x into the SoC software config > > registers region or bind them to constant values. > > The issue here is the "!int_active" condition for int_new_set_pending, > regardless of that configuration input. > > For interrupt sources that send pulses, those pulses will be lost if they are > received while int_active is true. So the driver has to make sure int_active is > false _before_ servicing an interrupt, or it may miss the next one. This means > the driver needs to know which interrupt _sources_ send pulses and which ones > assert levels. You are right, in plus mode, we can't receive any interrupt between claim & complete, then the irq could be lost. I think the design follows the sentence written by PLIC spec: https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc If the global interrupt source was edge-triggered, the gateway will convert the first matching signal edge into an interrupt request. Depending on the design of the device and the interrupt handler, in between sending an interrupt request and receiving notice of its handler’s completion, the gateway might either **ignore additional matching edges** or increment a counter of pending interrupts. Also, the hardware could easily support the feature, but the engineer follows the first choice and disable the useful function. -_*! > > For level interrupts, pad_plic_int_cfg_x had better be 0, but that is a > hardware/firmware configuration concern. The driver should not have to care > about that. > > (On the Allwinner D1, those inputs are memory mapped, which was the reason for > the stacked interrupt controller mentioned in my other reply. But while > pad_plic_int_cfg_x == 1 only works with edge interrupts, the pad_plic_int_cfg_x > == 0 choice works with either kind of interrupt source, so the stacked driver is > not really needed.) > > Regards, > Samuel -- Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/ _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2022-06-28 3:04 UTC|newest] Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-06-27 5:12 [PATCH v1 0/3] irqchip/sifive-plic: Fix T-HEAD PLIC edge trigger handling Samuel Holland 2022-06-27 5:12 ` Samuel Holland 2022-06-27 5:12 ` [PATCH v1 1/3] dt-bindings: interrupt-controller: Require trigger type for T-HEAD PLIC Samuel Holland 2022-06-27 5:12 ` Samuel Holland 2022-06-27 7:40 ` Guo Ren 2022-06-27 7:40 ` Guo Ren 2022-06-27 14:14 ` Samuel Holland 2022-06-27 14:14 ` Samuel Holland 2022-06-28 3:04 ` Guo Ren [this message] 2022-06-28 3:04 ` Guo Ren 2022-06-28 7:55 ` Guo Ren 2022-06-28 7:55 ` Guo Ren 2022-06-27 5:12 ` [PATCH v1 2/3] irqchip/sifive-plic: Name the chip more generically Samuel Holland 2022-06-27 5:12 ` Samuel Holland 2022-06-27 6:50 ` Guo Ren 2022-06-27 6:50 ` Guo Ren 2022-06-27 7:11 ` Marc Zyngier 2022-06-27 7:11 ` Marc Zyngier 2022-06-27 13:40 ` Samuel Holland 2022-06-27 13:40 ` Samuel Holland 2022-06-27 5:12 ` [PATCH v1 3/3] irqchip/sifive-plic: Fix T-HEAD PLIC edge trigger handling Samuel Holland 2022-06-27 5:12 ` Samuel Holland 2022-06-27 7:27 ` Marc Zyngier 2022-06-27 7:27 ` Marc Zyngier 2022-06-27 13:58 ` Samuel Holland 2022-06-27 13:58 ` 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='CAJF2gTR5Zb4TZbomVLbJdHG=JYrM9UkS4hxGeShXu0eu+SqpjQ@mail.gmail.com' \ --to=guoren@kernel.org \ --cc=aou@eecs.berkeley.edu \ --cc=biju.das.jz@bp.renesas.com \ --cc=devicetree@vger.kernel.org \ --cc=geert+renesas@glider.be \ --cc=krzysztof.kozlowski+dt@linaro.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-renesas-soc@vger.kernel.org \ --cc=linux-riscv@lists.infradead.org \ --cc=maz@kernel.org \ --cc=palmer@dabbelt.com \ --cc=paul.walmsley@sifive.com \ --cc=prabhakar.csengg@gmail.com \ --cc=prabhakar.mahadev-lad.rj@bp.renesas.com \ --cc=robh+dt@kernel.org \ --cc=sagar.kadam@sifive.com \ --cc=samuel@sholland.org \ --cc=tglx@linutronix.de \ /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.