Linux-MIPS Archive mirror
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: Thomas Gleixner <tglx@kernel.org>
Cc: Caleb James DeLisle <cjd@cjdns.fr>,
	linux-mips@vger.kernel.org,  robh@kernel.org, krzk+dt@kernel.org,
	conor+dt@kernel.org,  linux-kernel@vger.kernel.org,
	devicetree@vger.kernel.org
Subject: Re: [PATCH 2/2] irqchip/econet-en751221: Support MIPS 34Kc VEIC mode
Date: Sat, 2 May 2026 22:54:37 +0100 (BST)	[thread overview]
Message-ID: <alpine.DEB.2.21.2605022158400.23161@angie.orcam.me.uk> (raw)
In-Reply-To: <87tssuxmh8.ffs@tglx>

On Wed, 29 Apr 2026, Thomas Gleixner wrote:

> Other than those nits, this look like a reasonable solution for a
> completely unreasonable hardware design.

 Why do you think this design is unreasonable?

 How is that different, at the high level, from say the x86 APIC priority 
resolver and vector generator, combined with the interrupt descriptor 
table (except for additional optional GPR stack switching, which saves the 
handler from the hassle and extra cycles needed for GPR preservation, 
though I reckon with x86 you could use task gates in the IDT to yield a 
similar effect although at much higher cost performance-wise as x86 does 
not implement alternative GPR stacks)?

 Analogously to x86 in the MIPS VEIC mode the IRQ number is determined by 
the vector rather than the somewhat arbitrarily numbered (particularly in 
cascaded topologies) IRQ line and available to the handler in the 
CP0.Cause.RIPL register field.

 NB this arbitrary non-VEIC IRQ numbering is particularly obvious with 
MIPS platforms featuring an x86-style PCI southbridge with an embedded 
8259A interrupt controller pair, where for compatibility with our driver 
code we give root MIPS CPU IRQ lines numbers 16-23 while 8259A IRQ lines 
cascaded from one of the IRQ lines 18-23 are given numbers 0-15.

 Example such an odd topology:

           CPU0       
  0:          0   XT-PIC   0  timer
  1:          0   XT-PIC   1  i8042
  2:          0   XT-PIC   2  cascade
  3:          4   XT-PIC   3  ttyS1
  4:         37   XT-PIC   4  ttyS0
  6:          3   XT-PIC   6  floppy
  7:      52456   XT-PIC   7  parport0
  8:          0   XT-PIC   8  rtc0
 10:   99668740   XT-PIC  10  fddi0
 11:          0   XT-PIC  11  uhci_hcd:usb1
 12:          1   XT-PIC  12  i8042
 14:          0   XT-PIC  14  ata_piix
 15:         15   XT-PIC  15  ata_piix
 20:          0     MIPS   4  ttyS2
 21:          0     MIPS   5  CoreHi
 23:  803937130     MIPS   7  timer
ERR:          1

(where XT-PIC interrupts are cascaded from IRQ line 18/MIPS line 2, not 
actually given stub registration).  At least the VEIC mode brings some 
sanity here.

 FWIW,

  Maciej

      reply	other threads:[~2026-05-02 21:54 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-25 12:35 [PATCH 0/2] irqchip/econet-en751221: Support MIPS 34Kc VEIC mode Caleb James DeLisle
2026-04-25 12:35 ` [PATCH 1/2] dt-bindings: interrupt-controller: econet: Add CPU interrupt mapping Caleb James DeLisle
2026-04-25 13:28   ` Rob Herring (Arm)
2026-04-25 17:03     ` Caleb James DeLisle
2026-04-25 12:35 ` [PATCH 2/2] irqchip/econet-en751221: Support MIPS 34Kc VEIC mode Caleb James DeLisle
2026-04-29  7:19   ` Thomas Gleixner
2026-05-02 21:54     ` Maciej W. Rozycki [this message]

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=alpine.DEB.2.21.2605022158400.23161@angie.orcam.me.uk \
    --to=macro@orcam.me.uk \
    --cc=cjd@cjdns.fr \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=tglx@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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).