[patch] linux: New style IRQs for DECstation

[patch] linux: New style IRQs for DECstation

[Maciej W. Rozycki]

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: macro@ds2.pg.gda.pl, PGP key available        +

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

[Jun Sun]

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

Maciej W. Rozycki wrote:

> 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
> 
> 

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

[Maciej W. Rozycki]

On Mon, 8 Apr 2002, Jun Sun wrote:

> 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?

 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

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

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

[Jun Sun]

Maciej W. Rozycki wrote:

> On Mon, 8 Apr 2002, Jun Sun wrote:
> 
> 
>>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?
>>
> 
>  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. 
> 


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

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

[Maciej W. Rozycki]

On Mon, 8 Apr 2002, Jun Sun wrote:

> 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.

 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.

> In addition, conceptional you might have a system where FPU exception is 
> 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. 

> Of course abstraction and generalization can happen later when it becomes 
> 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

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

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

[Jun Sun]

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

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

[Maciej W. Rozycki]

On Tue, 9 Apr 2002, Jun Sun wrote:

> 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.

> Your patch will force every new CPU to add FPUEX option to the cpu_option, 
> 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.

> Leaving FPU exception enabled for a CPU that does not generate FPU exception 
> 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.

> It, however, makes sense to provide a common wrapper code for fpu interrupt to 
> 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

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +