From: Guo Ren <guoren@kernel.org> To: Anup Patel <anup@brainfault.org> Cc: "Marc Zyngier" <maz@kernel.org>, "Nikita Shubin" <nikita.shubin@maquefel.me>, "Atish Patra" <atish.patra@wdc.com>, "Thomas Gleixner" <tglx@linutronix.de>, "Palmer Dabbelt" <palmer@dabbelt.com>, "Heiko Stübner" <heiko@sntech.de>, "Rob Herring" <robh@kernel.org>, "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, linux-riscv <linux-riscv@lists.infradead.org>, "Guo Ren" <guoren@linux.alibaba.com> Subject: Re: [PATCH V5 3/3] irqchip/sifive-plic: Fixup thead, c900-plic request_threaded_irq with ONESHOT Date: Mon, 1 Nov 2021 11:57:04 +0800 [thread overview] Message-ID: <CAJF2gTRwi+yH-hQ0SHKDOuUf=OOMfJxQb6Q5m6xRCPjvbYjqaQ@mail.gmail.com> (raw) In-Reply-To: <CAAhSdy1WrxbMsiWkwOXd_76A6wNAh05C1QQ-oFXoE9U-F0akiA@mail.gmail.com> On Mon, Nov 1, 2021 at 10:53 AM Anup Patel <anup@brainfault.org> wrote: > > On Mon, Nov 1, 2021 at 7:50 AM Guo Ren <guoren@kernel.org> wrote: > > > > On Thu, Oct 28, 2021 at 10:58 PM Marc Zyngier <maz@kernel.org> wrote: > > > > > > On Thu, 28 Oct 2021 11:55:23 +0100, > > > Nikita Shubin <nikita.shubin@maquefel.me> wrote: > > > > > > > > Hello Marc and Guo Ren! > > > > > > > > On Mon, 25 Oct 2021 11:48:33 +0100 > > > > Marc Zyngier <maz@kernel.org> wrote: > > > > > > > > > On Sun, 24 Oct 2021 02:33:03 +0100, > > > > > guoren@kernel.org wrote: > > > > > > > > > > > > From: Guo Ren <guoren@linux.alibaba.com> > > > > > > > > > > > > When using "devm_request_threaded_irq(,,,,IRQF_ONESHOT,,)" in the > > > > > > driver, only the first interrupt could be handled, and continue irq > > > > > > is blocked by hw. Because the thead,c900-plic couldn't complete > > > > > > masked irq source which has been disabled in enable register. Add > > > > > > thead_plic_chip which fix up c906-plic irq source completion > > > > > > problem by unmask/mask wrapper. > > > > > > > > > > > > Here is the description of Interrupt Completion in PLIC spec [1]: > > > > > > > > > > > > The PLIC signals it has completed executing an interrupt handler by > > > > > > writing the interrupt ID it received from the claim to the > > > > > > claim/complete register. The PLIC does not check whether the > > > > > > completion ID is the same as the last claim ID for that target. If > > > > > > the completion ID does not match an interrupt source that is > > > > > > currently enabled for the target, the ^^ ^^^^^^^^^ ^^^^^^^ > > > > > > completion is silently ignored. > > > > > > > > > > Given this bit of the spec... > > > > > > > > > > > +static void plic_thead_irq_eoi(struct irq_data *d) > > > > > > +{ > > > > > > + struct plic_handler *handler = > > > > > > this_cpu_ptr(&plic_handlers); + > > > > > > + if (irqd_irq_masked(d)) { > > > > > > + plic_irq_unmask(d); > > > > > > + writel(d->hwirq, handler->hart_base + > > > > > > CONTEXT_CLAIM); > > > > > > + plic_irq_mask(d); > > > > > > + } else { > > > > > > + writel(d->hwirq, handler->hart_base + > > > > > > CONTEXT_CLAIM); > > > > > > + } > > > > > > +} > > > > > > + > > > > > > > > > > ... it isn't obvious to me why this cannot happen on an SiFive PLIC. > > > > > > > > This indeed happens with SiFive PLIC. I am currently tinkering with > > > > da9063 RTC on SiFive Unmatched, and ALARM irq fires only once. However > > > > with changes proposed by Guo Ren in plic_thead_irq_eoi, everything > > > > begins to work fine. > > > > > > > > May be these change should be propagated to plic_irq_eoi instead of > > > > making a new function ? > > > > > > That's my impression too. I think the T-Head defect is pretty much > > > immaterial when you consider how 'interesting' the PLIC architecture > > > is. > > Which is the "T-Head defect" you mentioned here? > > 1. Auto masking with claim + complete (I don't think it's a defect, > > right? May I add a new patch to utilize the feature to decrease a > > little duplicate mask/unmask operations in the future?) > > This is definitely a defect and non-compliance for T-HEAD because I just agree with non-compliance, but what's the defect of auto-masking? If somebody could explain, I'm very grateful. > no sane interrupt controller would mask interrupt upon claim and this > is not what RISC-V PLIC defines. > > > 2. EOI failed when masked > > This defect exists for both RISC-V PLIC and T-HEAD PLIC > because of the way interrupt completion is defined. > > > > > > Conflating EOI and masking really is a misfeature... > > I think the problem is riscv PLIC reuse enable bit as mask bit. I > > recommend separating them. That means: > > There are no per-interrupt mask bits. We only have per-context > and per-interrupt enable bits which is used to provide mask/unmask > functionality expected by the irqchip framework. > > I don't see how this is a problem for RISC-V PLIC. The only real > issue with RISC-V PLIC is the fact the interrupt completion will be > ignored for a masked interrupt which is what Marc is pointing at. So you are not considering add per-interrupt mask bits to solve the above problem, right? I don't think you would keep below codes in AIA eoi. + plic_irq_unmask(d); + writel(d->hwirq, handler->hart_base + CONTEXT_CLAIM); + plic_irq_mask(d); > > Regards, > Anup > > > - EOI still depends on enable bit. > > - Add mask/unmask bit regs to do the right thing. > > > > > > > > > > > M. > > > > > > -- > > > Without deviation from the norm, progress is not possible. > > > > > > > > -- > > Best Regards > > Guo Ren > > > > ML: https://lore.kernel.org/linux-csky/ -- 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
WARNING: multiple messages have this Message-ID (diff)
From: Guo Ren <guoren@kernel.org> To: Anup Patel <anup@brainfault.org> Cc: "Marc Zyngier" <maz@kernel.org>, "Nikita Shubin" <nikita.shubin@maquefel.me>, "Atish Patra" <atish.patra@wdc.com>, "Thomas Gleixner" <tglx@linutronix.de>, "Palmer Dabbelt" <palmer@dabbelt.com>, "Heiko Stübner" <heiko@sntech.de>, "Rob Herring" <robh@kernel.org>, "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, linux-riscv <linux-riscv@lists.infradead.org>, "Guo Ren" <guoren@linux.alibaba.com> Subject: Re: [PATCH V5 3/3] irqchip/sifive-plic: Fixup thead, c900-plic request_threaded_irq with ONESHOT Date: Mon, 1 Nov 2021 11:57:04 +0800 [thread overview] Message-ID: <CAJF2gTRwi+yH-hQ0SHKDOuUf=OOMfJxQb6Q5m6xRCPjvbYjqaQ@mail.gmail.com> (raw) In-Reply-To: <CAAhSdy1WrxbMsiWkwOXd_76A6wNAh05C1QQ-oFXoE9U-F0akiA@mail.gmail.com> On Mon, Nov 1, 2021 at 10:53 AM Anup Patel <anup@brainfault.org> wrote: > > On Mon, Nov 1, 2021 at 7:50 AM Guo Ren <guoren@kernel.org> wrote: > > > > On Thu, Oct 28, 2021 at 10:58 PM Marc Zyngier <maz@kernel.org> wrote: > > > > > > On Thu, 28 Oct 2021 11:55:23 +0100, > > > Nikita Shubin <nikita.shubin@maquefel.me> wrote: > > > > > > > > Hello Marc and Guo Ren! > > > > > > > > On Mon, 25 Oct 2021 11:48:33 +0100 > > > > Marc Zyngier <maz@kernel.org> wrote: > > > > > > > > > On Sun, 24 Oct 2021 02:33:03 +0100, > > > > > guoren@kernel.org wrote: > > > > > > > > > > > > From: Guo Ren <guoren@linux.alibaba.com> > > > > > > > > > > > > When using "devm_request_threaded_irq(,,,,IRQF_ONESHOT,,)" in the > > > > > > driver, only the first interrupt could be handled, and continue irq > > > > > > is blocked by hw. Because the thead,c900-plic couldn't complete > > > > > > masked irq source which has been disabled in enable register. Add > > > > > > thead_plic_chip which fix up c906-plic irq source completion > > > > > > problem by unmask/mask wrapper. > > > > > > > > > > > > Here is the description of Interrupt Completion in PLIC spec [1]: > > > > > > > > > > > > The PLIC signals it has completed executing an interrupt handler by > > > > > > writing the interrupt ID it received from the claim to the > > > > > > claim/complete register. The PLIC does not check whether the > > > > > > completion ID is the same as the last claim ID for that target. If > > > > > > the completion ID does not match an interrupt source that is > > > > > > currently enabled for the target, the ^^ ^^^^^^^^^ ^^^^^^^ > > > > > > completion is silently ignored. > > > > > > > > > > Given this bit of the spec... > > > > > > > > > > > +static void plic_thead_irq_eoi(struct irq_data *d) > > > > > > +{ > > > > > > + struct plic_handler *handler = > > > > > > this_cpu_ptr(&plic_handlers); + > > > > > > + if (irqd_irq_masked(d)) { > > > > > > + plic_irq_unmask(d); > > > > > > + writel(d->hwirq, handler->hart_base + > > > > > > CONTEXT_CLAIM); > > > > > > + plic_irq_mask(d); > > > > > > + } else { > > > > > > + writel(d->hwirq, handler->hart_base + > > > > > > CONTEXT_CLAIM); > > > > > > + } > > > > > > +} > > > > > > + > > > > > > > > > > ... it isn't obvious to me why this cannot happen on an SiFive PLIC. > > > > > > > > This indeed happens with SiFive PLIC. I am currently tinkering with > > > > da9063 RTC on SiFive Unmatched, and ALARM irq fires only once. However > > > > with changes proposed by Guo Ren in plic_thead_irq_eoi, everything > > > > begins to work fine. > > > > > > > > May be these change should be propagated to plic_irq_eoi instead of > > > > making a new function ? > > > > > > That's my impression too. I think the T-Head defect is pretty much > > > immaterial when you consider how 'interesting' the PLIC architecture > > > is. > > Which is the "T-Head defect" you mentioned here? > > 1. Auto masking with claim + complete (I don't think it's a defect, > > right? May I add a new patch to utilize the feature to decrease a > > little duplicate mask/unmask operations in the future?) > > This is definitely a defect and non-compliance for T-HEAD because I just agree with non-compliance, but what's the defect of auto-masking? If somebody could explain, I'm very grateful. > no sane interrupt controller would mask interrupt upon claim and this > is not what RISC-V PLIC defines. > > > 2. EOI failed when masked > > This defect exists for both RISC-V PLIC and T-HEAD PLIC > because of the way interrupt completion is defined. > > > > > > Conflating EOI and masking really is a misfeature... > > I think the problem is riscv PLIC reuse enable bit as mask bit. I > > recommend separating them. That means: > > There are no per-interrupt mask bits. We only have per-context > and per-interrupt enable bits which is used to provide mask/unmask > functionality expected by the irqchip framework. > > I don't see how this is a problem for RISC-V PLIC. The only real > issue with RISC-V PLIC is the fact the interrupt completion will be > ignored for a masked interrupt which is what Marc is pointing at. So you are not considering add per-interrupt mask bits to solve the above problem, right? I don't think you would keep below codes in AIA eoi. + plic_irq_unmask(d); + writel(d->hwirq, handler->hart_base + CONTEXT_CLAIM); + plic_irq_mask(d); > > Regards, > Anup > > > - EOI still depends on enable bit. > > - Add mask/unmask bit regs to do the right thing. > > > > > > > > > > > M. > > > > > > -- > > > Without deviation from the norm, progress is not possible. > > > > > > > > -- > > Best Regards > > Guo Ren > > > > ML: https://lore.kernel.org/linux-csky/ -- Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/
next prev parent reply other threads:[~2021-11-01 3:57 UTC|newest] Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-10-24 1:33 [PATCH V5 0/3] Add thead,c900-plic support guoren 2021-10-24 1:33 ` guoren 2021-10-24 1:33 ` [PATCH V5 1/3] dt-bindings: vendor-prefixes: add T-Head Semiconductor guoren 2021-10-24 1:33 ` guoren 2021-11-02 2:21 ` Guo Ren 2021-11-02 2:21 ` Guo Ren 2021-11-02 12:59 ` Rob Herring 2021-11-02 12:59 ` Rob Herring 2021-11-03 1:52 ` Guo Ren 2021-11-03 1:52 ` Guo Ren 2021-10-24 1:33 ` [PATCH V5 2/3] dt-bindings: update riscv plic compatible string guoren 2021-10-24 1:33 ` guoren 2021-10-24 7:35 ` Anup Patel 2021-10-24 7:35 ` Anup Patel 2021-10-24 9:01 ` Guo Ren 2021-10-24 9:01 ` Guo Ren 2021-10-24 9:18 ` Anup Patel 2021-10-24 9:18 ` Anup Patel 2021-10-24 9:35 ` Guo Ren 2021-10-24 9:35 ` Guo Ren 2021-10-24 9:52 ` Anup Patel 2021-10-24 9:52 ` Anup Patel 2021-10-24 10:04 ` Guo Ren 2021-10-24 10:04 ` Guo Ren 2021-10-24 1:33 ` [PATCH V5 3/3] irqchip/sifive-plic: Fixup thead, c900-plic request_threaded_irq with ONESHOT guoren 2021-10-24 1:33 ` [PATCH V5 3/3] irqchip/sifive-plic: Fixup thead,c900-plic " guoren 2021-10-25 10:48 ` Marc Zyngier 2021-10-25 10:48 ` [PATCH V5 3/3] irqchip/sifive-plic: Fixup thead, c900-plic " Marc Zyngier 2021-10-25 13:33 ` [PATCH V5 3/3] irqchip/sifive-plic: Fixup thead,c900-plic " Guo Ren 2021-10-25 13:33 ` Guo Ren 2021-10-28 10:55 ` [PATCH V5 3/3] irqchip/sifive-plic: Fixup thead, c900-plic " Nikita Shubin 2021-10-28 10:55 ` Nikita Shubin 2021-10-28 14:58 ` Marc Zyngier 2021-10-28 14:58 ` Marc Zyngier 2021-10-30 10:27 ` Anup Patel 2021-10-30 10:27 ` Anup Patel 2021-11-01 2:20 ` Guo Ren 2021-11-01 2:20 ` Guo Ren 2021-11-01 2:53 ` Anup Patel 2021-11-01 2:53 ` Anup Patel 2021-11-01 3:57 ` Guo Ren [this message] 2021-11-01 3:57 ` Guo Ren 2021-11-01 4:27 ` Anup Patel 2021-11-01 4:27 ` Anup Patel 2021-11-01 7:56 ` Guo Ren 2021-11-01 7:56 ` Guo Ren 2021-11-01 9:27 ` Marc Zyngier 2021-11-01 9:27 ` Marc Zyngier 2021-11-01 9:25 ` Marc Zyngier 2021-11-01 9:25 ` Marc Zyngier 2021-11-01 2:00 ` Guo Ren 2021-11-01 2:00 ` Guo Ren 2021-11-01 5:11 ` Vincent Pelletier 2021-11-01 5:11 ` Vincent Pelletier
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='CAJF2gTRwi+yH-hQ0SHKDOuUf=OOMfJxQb6Q5m6xRCPjvbYjqaQ@mail.gmail.com' \ --to=guoren@kernel.org \ --cc=anup@brainfault.org \ --cc=atish.patra@wdc.com \ --cc=guoren@linux.alibaba.com \ --cc=heiko@sntech.de \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-riscv@lists.infradead.org \ --cc=maz@kernel.org \ --cc=nikita.shubin@maquefel.me \ --cc=palmer@dabbelt.com \ --cc=robh@kernel.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.