[snip]
Maybe my message was misleading everything has been tested and works correctly
on multiple SoCs because ECONET_SOC_EN751221 does not select EI/VI. Answering
this question will allow me to enable them, thus also getting
MIPS_MT_SMP.
It does not select it, but it can be enabled independently or through
some other magic config knob, right? And if it gets enabled, then it
does not work, right?
Not really true on either point.
Firstly, it's not something you can select in the kernel menuconfig, it's
selected by the SoC or some core feature of the SoC (e.g. SMP_MT_MIPS).
Secondly it does work, it's just that it does what it says it does, and you
need to handle those vectored interrupts - no irqchip driver does this.
I could look at forbidding them in the driver, but I'm not sure that's
appropriate as this seems like more of an SoC issue than an INTC
issue. But I'll follow your guidance.
What's not appropriate? If it does not work, then it's very appropriate
to do
config ECONET
depends on !EI && !VI
on the principle of least surprise, no?
I've spent quite a bit of time studying this, so with respect for your time,
let me try to give you a brief summary of what I know and why I
submitted this as I did:
1. EI/VI is supported by the intc but it's really a feature of MIPS32r2.
In MIPS32r2, the CPU<->intc wire interface allows the CPU to send its
interrupts to the intc, and then allows the intc to fire any of of up to
64 interrupts back to the CPU.
2. When enabled, the CPU's internal intc sends its 7 interrupts to the
external intc who prioritizes them, renumbers them, and sends them
back along with their own.
3. When they come back, the CPU tries to be helpful by dispatching to an
offset within a vector table depending on the interrupt number.
4. The real problem with this is IRQ_MIPS_CPU no longer gets its 7
interrupts because they've been renumbered.
5. MIPS 1004Kc uses a standard intc (IRQ_GIC), and they solved this by
not really using the feature. Despite having 64 lines, they only send on
one and they make the driver poll to find out what's pending. I believe
they also return the CPU's 7 interrupts without renumbering.
6. But in 34Kc world there is no standard intc, and AFAICT many (most?)
of them fully use the EI/VI feature.
7. If you don't set EI/VI, the processor goes into / stays in legacy mode,
so it doesn't send anything to the intc, and everything the intc sends to
it is converted to a hit on line 2 - so as long as the intc has some
kind of pending register, chaining works.
8. But without EI/VI you can't have MT_SMP so you only get one thread.
9. In every 34Kc SoC I've found in Linux or OpenWRT, EI/VI is
conspicuously missing (with one exception). Clearly they had a
compelling reason for doing it, and I *think* that reason is because
they all faced the same issue as me and solved it the same way.
10. The exception is irq-realtek-rtl, which via an out-of-tree patch[1]
was able to enable EI/VI and I have no idea what they're doing, but it
appears that their intc hardware is participating, like with GIC.
11. I did implement an EI/VI dispatcher myself and had it working with
SMP, but I shelved because it's complex and it's not tightly coupled to
the intc driver itself so I concluded that it should be a separate
component that works with any intc. The complexity comes from the
fact that you need to either route the software interrupts back to
IRQ_MIPS_CPU's domain and fix the renumbering, or else implement
your own IPI subsystem.
So it's my belief that what I'm doing here is standard for 34Kc.
The reason I asked the question in the beginning was because I wanted
to check my assumptions and know if there's any way I can get SMP
without writing this dispatcher.
So this patch clearly should have been tagged with 'RFC'.
Given the patchset works correctly in testing, does this comment
stand?
Until the EI/VI issue is resolved so that it either works or cannot
happen.
All said, if "depends on !EI && !VI" makes you happy then I'm OK to add it.
Just what I'm afraid of is being asked to find an authoritative answer to my
question before merging, because if nobody decides to jump in with one
then this could just be blocked indefinitely.
Thanks,
Caleb
[1]:
https://github.com/openwrt/openwrt/blob/main/target/linux/realtek/patches-6.6/314-irqchip-irq-realtek-rtl-add-VPE-support.patch
+static int econet_intc_map(struct irq_domain *d, u32 irq, irq_hw_number_t hwirq)
+{
+ int ret;
+
+ if (hwirq >= INTC_IRQ_COUNT) {
+ pr_err("%s: hwirq %lu out of range\n", __func__, hwirq);
+ return -EINVAL;
+ } else if (econet_intc_rai.shadow_interrupts[hwirq] == INTC_IS_SHADOW) {
+ pr_err("%s: can't map hwirq %lu, it is a shadow interrupt\n",
+ __func__, hwirq);
No newline
If I understand correctly, you prefer:
.....interrupt\n", __func__, hwirq);
for a 96 char line?
You have 100 characters in drivers/irqchip/
+ .domain_ops = {
+ .xlate = irq_domain_xlate_onecell,
+ .map = econet_intc_map,
See documention.
I suppose this is tab alignment, but I will in any case make a point
of reading it all carefully.
Yes. The aligned tabular view is way simpler to read and parse. Reading
is based on pattern recognition. Irregular patterns disturb the reading
flow, which means the focus is shifted from understanding to decoding
the irregular pattern.
In case of any doubt, I wasn't trying to sneak bad code past you.
I did not assume malice here at all.
Thanks,
tglx
