Subject: [patch] linux: New style IRQs for DECstation

From: "Maciej W. Rozycki" <[email-masked]>
Date: Mon, 8 Apr 2002 19:04:12 +0200 (MET DST)

Hello,

 Here is code that implements new style IRQ handlers for DECstation. 
Beside obvious things, like mask/unmask, etc. functions it adds IRQ
routing tables for individual systems (including somewhat more complete
basic support for the 5100) so that device drivers for onboard devices do
not have to code IRQ guesswork based on model types.  I tried to make
hardware documentation more complete as well as its external sources are
scarce to say at least, so it might be best to keep bits described within
the code that deals with them. 

 Also included there are a few updates to generic code:

1. A few clean-ups to arch/mips/kernel/irq_cpu.c.  Just a five minute
approach to fix obvious things.  A deeper action is needed, in particular
locking is missing altogether.

2. A new mips_cpu option to denote the dedicated FPU exception is present
as there is currently no sane way to conclude whether it's available or
not.

3. A few missing header inclusions.

 Actually the code is nothing new, but since I'm resubmitting it and a few
people confirmed their interest in the DECstation port since the previous
submission, I'm making the patch available to the public.  I'm running the
code since mid January successfully with only a few minor fixes since
then.

 Due to a relatively large size the patch is available here:
'ftp://ftp.ds2.pg.gda.pl/pub/macro/linux/patch-mips-2.4.18-20020402-irq-48.gz'.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: [email-masked], PGP key available        +

---

From: Jun Sun <[email-masked]>
Date: Mon, 08 Apr 2002 10:48:22 -0700

What is the intention of introducing MIPS_CPU_FPUEX?  It seems an overkill if 
it is just needed by DecStation.  How many CPUs really need this?

Jun

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Mon, 8 Apr 2002 20:03:43 +0200 (MET DST)

> it is just needed by DecStation.  How many CPUs really need this?

 It's needed by any system using a (logically) external FPU.  If set it
means there is no need to install a special FPU exception handler using a
general-purpose interrupt line.  It's a generic flag. 

 Even if it's only of limited use now, it is not an excuse for not writing
clean code.  I'm afraid the current mess within the MIPS port is a result
of people trying to think locally and I'm trying to avoid it.  Are there
any trade-offs of this flags you see and I don't?  I'm willing to change
the code if there really are. 

  Maciej

---

From: Jun Sun <[email-masked]>
Date: Mon, 08 Apr 2002 11:25:54 -0700

> the code if there really are. 

Generally interrupt dispatching belongs to machine/board-specific code.  So I 
think FPU exeption through an interrupt is probably best handled within DEC's 
code, instead of being generalized to the common code.

In addition, conceptional you might have a system where FPU exception is 
handled through an interrupt and yet CPU has FPU exception.

Of course abstraction and generalization can happen later when it becomes 
obvious.  It is just not obvious, at least to me.

Jun

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Tue, 9 Apr 2002 16:41:33 +0200 (MET DST)

> code, instead of being generalized to the common code.

 The dispatching of the FPU interrupt for the DECstation is local to
DEC-specific code (note that it's so mainly due to performance reasons
anyway -- there is no problem with making dispatcher's code common with
appropriate backends installed for different IRQ types, like it is already
done in generic controller-based IRQ handling code).  Any other system
using a CPU/FPU in such a configuration has to provide its own dispatcher.
The handler for the FPU interrupt is the very same handler used for the
FPU exception; only a different entry point is used to accomodate the fact
registers are already saved on the stack. 

 And for safety you don't want the FPU exception handler to be enabled for
FPUs that report exceptions via an FPU interrupt.  For such systems a
spurious FPU exception should be treated as a system error.

> handled through an interrupt and yet CPU has FPU exception.

 Not quite.  The FPU exception is not maskable, so you can't make a choice
at the run time.  It has to be hardwired. 

> obvious.  It is just not obvious, at least to me.

 MIPS_CPU_FPUEX is specific to the CPU not to the system.  IDT R3081 is
another example (mysterious R3400 used in DECstation 5000/240 being the
first one) of a CPU with an integrated FPU unit which is logically
external and uses an interrupt to report FPU exceptions.  And all R2k/R3k
setups using a physically separate FPU deliver FPU exceptions via an
interrupt line.  I can't see a reason why to handle this option in
system-specific code.

  Maciej

---

From: Jun Sun <[email-masked]>
Date: Tue, 09 Apr 2002 10:36:20 -0700

Maciej W. Rozycki wrote:

> I can't see a reason why to handle this option in
> system-specific code.
> 

How about "there will be likely no such CPUs/systems in the future"?

Your patch will force every new CPU to add FPUEX option to the cpu_option, 
where apparently no place really need to use it.

Leaving FPU exception enabled for a CPU that does not generate FPU exception 
is acceptable. (because it does *not* generate FPU exceptions).  And hooking 
up/dispatching the FPU exception interrupt is system-specific already anyway.

It, however, makes sense to provide a common wrapper code for fpu interrupt to 
jump to fpu exception handling code.

Over-abstraction can make the picture cloudy rather than clear.  My 2 cents.

Jun

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Wed, 10 Apr 2002 15:31:07 +0200 (MET DST)

> How about "there will be likely no such CPUs/systems in the future"?

 Does it mean code needs to be dirty?  There is no performance hit for new
CPUs and the code bloat is minimal and even that is discarded after boot.

> where apparently no place really need to use it.

 Well, I agree to some extent here.  I may negate the flag, so it's not
needed for most CPUs.

> is acceptable. (because it does *not* generate FPU exceptions).  And hooking 

 You never know.  You may get one due to a hardware fault.  It's better to
trap it and panic then, than to try to pretend nothing special happened.

> up/dispatching the FPU exception interrupt is system-specific already anyway.

 But pretty generic -- you just need to grab the right IRQ line.  See the
top of decstation_handle_int in arch/mips/dec/int-handler.S -- nothing
system-specific until after the FPU path branch.  You may cut and paste it
for any other system.

> jump to fpu exception handling code.

 No additional code is actually generated -- only a label for a second
entry point is added.

> Over-abstraction can make the picture cloudy rather than clear.  My 2 cents.

 I appreciate your point of view.  You haven't convinced me, though. 
Apart from the negation of MIPS_CPU_FPUEX, which sounds reasonable indeed. 

  Maciej