From: Marc Zyngier <maz@kernel.org>
To: Jessica Clarke <jrtc27@jrtc27.com>
Cc: Anup Patel <anup@brainfault.org>,
Anup Patel <apatel@ventanamicro.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Thomas Gleixner <tglx@linutronix.de>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Atish Patra <atishp@atishpatra.org>,
Alistair Francis <Alistair.Francis@wdc.com>,
linux-riscv <linux-riscv@lists.infradead.org>,
"linux-kernel@vger.kernel.org List"
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 2/6] irqchip/riscv-intc: Create domain using named fwnode
Date: Mon, 21 Feb 2022 09:25:08 +0000 [thread overview]
Message-ID: <87ee3w4lmz.wl-maz@kernel.org> (raw)
In-Reply-To: <4A07582C-80BD-41F8-AEF5-EE48EB7D2D15@jrtc27.com>
On Sat, 19 Feb 2022 14:51:22 +0000,
Jessica Clarke <jrtc27@jrtc27.com> wrote:
>
> On 19 Feb 2022, at 09:32, Marc Zyngier <maz@kernel.org> wrote:
> >
> > But how do you plan to work around the fact that everything is currently
> > build around having a node (and an irqdomain) per CPU? The PLIC, for example,
> > clearly has one parent per CPU, not one global parent.
> >
> > I'm sure there was a good reason for this, and I suspect merging the domains
> > will simply end up breaking things.
>
> On the contrary, the drivers rely on the controller being the same
> across all harts, with riscv_intc_init skipping initialisation for all
> but the boot hart’s controller. The bindings are a complete pain to
> deal with as a result, what you *want* is like you have in the Arm
> world where there is just one interrupt controller in the device tree
> with some of the interrupts per-processor, but instead we have this
> overengineered nuisance. The only reason there are per-hart interrupt
> controllers is because that’s how the contexts for the CLINT/PLIC are
> specified, but that really should have been done another way rather
> than abusing the interrupts-extended property for that. In the FreeBSD
> world we’ve been totally ignoring the device tree nodes for the local
> interrupt controllers but for my AIA and ACLINT branch I started a few
> months ago (though ACLINT's now been completely screwed up by RVI
> politics, things have been renamed and split up differently in the past
> few days and software interrupts de-prioritised with no current path to
> ratification, so that was a waste of my time) I just hang the driver
> off the boot hart’s node and leave all the others as totally ignored
> and a waste of space other than to figure out the contexts for the PLIC
> etc.
>
> TL;DR yes the bindings are awful, no there’s no issue with merging the
> domains.
I don't know how that flies with something like[1], where CPU0 only
gets interrupts in M-Mode and not S-Mode. Maybe it doesn't really
matter, but this sort of asymmetric routing is totally backward.
It sometime feels like the RV folks are actively trying to make this
architecture a mess... :-/
M.
[1] CAAhSdy0jTTDzoc+3T_8uLiWfBN3AFCWj99Ayc-Yh8FBfzUY2sQ@mail.gmail.com
--
Without deviation from the norm, progress is not possible.
_______________________________________________
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: Marc Zyngier <maz@kernel.org>
To: Jessica Clarke <jrtc27@jrtc27.com>
Cc: Anup Patel <anup@brainfault.org>,
Anup Patel <apatel@ventanamicro.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Thomas Gleixner <tglx@linutronix.de>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Atish Patra <atishp@atishpatra.org>,
Alistair Francis <Alistair.Francis@wdc.com>,
linux-riscv <linux-riscv@lists.infradead.org>,
"linux-kernel@vger.kernel.org List"
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 2/6] irqchip/riscv-intc: Create domain using named fwnode
Date: Mon, 21 Feb 2022 09:25:08 +0000 [thread overview]
Message-ID: <87ee3w4lmz.wl-maz@kernel.org> (raw)
In-Reply-To: <4A07582C-80BD-41F8-AEF5-EE48EB7D2D15@jrtc27.com>
On Sat, 19 Feb 2022 14:51:22 +0000,
Jessica Clarke <jrtc27@jrtc27.com> wrote:
>
> On 19 Feb 2022, at 09:32, Marc Zyngier <maz@kernel.org> wrote:
> >
> > But how do you plan to work around the fact that everything is currently
> > build around having a node (and an irqdomain) per CPU? The PLIC, for example,
> > clearly has one parent per CPU, not one global parent.
> >
> > I'm sure there was a good reason for this, and I suspect merging the domains
> > will simply end up breaking things.
>
> On the contrary, the drivers rely on the controller being the same
> across all harts, with riscv_intc_init skipping initialisation for all
> but the boot hart’s controller. The bindings are a complete pain to
> deal with as a result, what you *want* is like you have in the Arm
> world where there is just one interrupt controller in the device tree
> with some of the interrupts per-processor, but instead we have this
> overengineered nuisance. The only reason there are per-hart interrupt
> controllers is because that’s how the contexts for the CLINT/PLIC are
> specified, but that really should have been done another way rather
> than abusing the interrupts-extended property for that. In the FreeBSD
> world we’ve been totally ignoring the device tree nodes for the local
> interrupt controllers but for my AIA and ACLINT branch I started a few
> months ago (though ACLINT's now been completely screwed up by RVI
> politics, things have been renamed and split up differently in the past
> few days and software interrupts de-prioritised with no current path to
> ratification, so that was a waste of my time) I just hang the driver
> off the boot hart’s node and leave all the others as totally ignored
> and a waste of space other than to figure out the contexts for the PLIC
> etc.
>
> TL;DR yes the bindings are awful, no there’s no issue with merging the
> domains.
I don't know how that flies with something like[1], where CPU0 only
gets interrupts in M-Mode and not S-Mode. Maybe it doesn't really
matter, but this sort of asymmetric routing is totally backward.
It sometime feels like the RV folks are actively trying to make this
architecture a mess... :-/
M.
[1] CAAhSdy0jTTDzoc+3T_8uLiWfBN3AFCWj99Ayc-Yh8FBfzUY2sQ@mail.gmail.com
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2022-02-21 10:21 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-28 5:24 [PATCH v2 0/6] RISC-V IPI Improvements Anup Patel
2022-01-28 5:24 ` Anup Patel
2022-01-28 5:25 ` [PATCH v2 1/6] RISC-V: Clear SIP bit only when using SBI IPI operations Anup Patel
2022-01-28 5:25 ` Anup Patel
2022-01-28 5:25 ` [PATCH v2 2/6] irqchip/riscv-intc: Create domain using named fwnode Anup Patel
2022-01-28 5:25 ` Anup Patel
2022-02-17 15:12 ` Marc Zyngier
2022-02-17 15:12 ` Marc Zyngier
2022-02-19 3:38 ` Anup Patel
2022-02-19 3:38 ` Anup Patel
2022-02-19 9:32 ` Marc Zyngier
2022-02-19 9:32 ` Marc Zyngier
2022-02-19 13:03 ` Anup Patel
2022-02-19 13:03 ` Anup Patel
2022-02-21 9:07 ` Marc Zyngier
2022-02-21 9:07 ` Marc Zyngier
2022-02-21 9:38 ` Anup Patel
2022-02-21 9:38 ` Anup Patel
2022-02-19 14:51 ` Jessica Clarke
2022-02-19 14:51 ` Jessica Clarke
2022-02-21 9:25 ` Marc Zyngier [this message]
2022-02-21 9:25 ` Marc Zyngier
2022-02-21 9:44 ` Anup Patel
2022-02-21 9:44 ` Anup Patel
2022-01-28 5:25 ` [PATCH v2 3/6] RISC-V: Treat IPIs as normal Linux IRQs Anup Patel
2022-01-28 5:25 ` Anup Patel
2022-01-28 5:25 ` [PATCH v2 4/6] RISC-V: Allow marking IPIs as suitable for remote FENCEs Anup Patel
2022-01-28 5:25 ` Anup Patel
2022-01-28 5:25 ` [PATCH v2 5/6] RISC-V: Use IPIs for remote TLB flush when possible Anup Patel
2022-01-28 5:25 ` Anup Patel
2022-01-28 5:25 ` [PATCH v2 6/6] RISC-V: Use IPIs for remote icache " Anup Patel
2022-01-28 5:25 ` Anup Patel
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=87ee3w4lmz.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=Alistair.Francis@wdc.com \
--cc=anup@brainfault.org \
--cc=apatel@ventanamicro.com \
--cc=atishp@atishpatra.org \
--cc=daniel.lezcano@linaro.org \
--cc=jrtc27@jrtc27.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--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: link
Be 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.