[PATCH 0/2] external interrupts

[PATCH 0/2] external interrupts

[Brent Casavant]

Here is a set of patches that implements an external interrupt capability
in Linux, along with a device driver for a specific hardware device.  I
submitted the patches several weeks ago, and they drew no comments, which
I take to be a good sign.  Anyway, I'm hoping these can be picked up for
-mm in time for 2.6.14.

External interrupts, in short, encompass the ability to respond quickly
via an interrupt routine to an externally applied voltage signal.  This
finds use primarily in real time systems which must react to an event
generated outside the computer.  External interrupts also encompass
the ability to generate such signals in order to notify other computer
systems (or even the same system, depending on cabling and configuration)
of an event of interest.  This is explained in greater detail in the
Documentation/extint.txt and Documentation/sgi-ioc4.txt files which are
part of these patches.

The first patch implements an abstraction layer which creates a sysfs
class "extint".  This class provides device control via several (hopefully)
common attributes of an external interrupt device.  For example, an
application can control the source of ingested interrupts if multiple
input jacks are present on the specific hardware, or control the output
waveform and repetition period on the output side.  Mechanisms are
provided to allow a low-level driver to enumerate these capabilities
where appropriate.

This first patch is motivated by several factors.  The first is a clean
seperation of device-specific knowledge from the more general concept, thus
isolating applications from needing to be aware of device characteristics.
The second is the simplification of low-level external interrupt drivers
by centralizing the common factors (e.g. a global counter, a list of
actions to invoke at each interrupt, etc) in the abstraction layer.
Finally, it enables easy support for additional or alternative low-level
(i.e. device-specific) external interrupt drivers in the future.

The second patch implements the low-level external interrupt driver for
the SGI IOC4 I/O controller chip.  For the most part this driver simply
registers itself with the extint abstraction layer, and of course takes
care of all the hardware bit-twiddling to effect appropriate operation.
In addition, this driver provides its own character special device which
can be mmap'd directly into the user address space.  This provides the
ability to control interrupt output generation without going through
the abstraction layer's sysfs attribute's read/write routines by directly
poking values in the appropriate hardware register (which lives in its
own page of memory seperate from all others).  This capability enables
the application to more expediently generate output where this bit of
overhead might matter (remember, this is typically used in real time
or near real time systems).

I do realize this whole thing is slightly overengineered if only to enable
the IOC4 device's external interrupt capability.  However, like all
hardware, someday IOC4 will be a long-forgotten memory, and SGI (me in
particular) would like to put a suitable mechanism in place to enable
different types of hardware with similar capabilities in the future.
Hopefully any interested third-party hardware vendors will add their
own low-level external interrupt drivers.

And while I mentioned real time as the primary application of external
interrupts, I'm sure there are other creative uses to be found.  My
imagination, however, is limited. :)

Thanks,
Brent Casavant

-- 
Brent Casavant                          If you had nothing to fear,
bcasavan@sgi.com                        how then could you be brave?
Silicon Graphics, Inc.                    -- Queen Dama, Source Wars

Re: [PATCH 0/2] external interrupts

[Pavel Machek]

Hi!

> Here is a set of patches that implements an external interrupt capability
> in Linux, along with a device driver for a specific hardware device.  I
> submitted the patches several weeks ago, and they drew no comments, which
> I take to be a good sign.  Anyway, I'm 
It was not good sign in this particular case. My reaction was "this is _so_
overengineered tjat he's probably joking".

				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: [PATCH 0/2] external interrupts

[Brent Casavant]

On Sun, 21 Aug 2005, Pavel Machek wrote:

> > Here is a set of patches that implements an external interrupt capability
> > in Linux, along with a device driver for a specific hardware device.  I
> > submitted the patches several weeks ago, and they drew no comments, which
> > I take to be a good sign.  Anyway, I'm 
> It was not good sign in this particular case. My reaction was "this is _so_
> overengineered tjat he's probably joking".

Laughter was not wholly unexpected, though I wasn't joking.  I'm trying
to be realistic about the lifetime of any given hardware, and IOC4 is
several years old at this point.  Couple that with a sincere desire to
preserve application source compatability when (not if) new hardware
appears, and an abstraction layer seemed to be a logical choice.  I'm
more than happy to discuss problems in the abstraction layer's interface
and make appropriate changes -- I'm nothing if not obliging.

I do recognize that the code is a bit excessive given that there's
only one known device (IOC4) that is currently supported.  However,
the abstraction isn't really all that complicated.  The low-level
driver simply provides to the abstraction layer a structure containing
a handful of functions pointers: get/set output modes and timings,
get/set interrupt sources, get timing roundoff information and device
ID.  The abstraction layer provides a function to call whenever an
interrupt occurs.  Then add in a bit of registration/deregistration
glue so that kernel modules can load and unload.  That's pretty much it
-- nothing fancier than needed to decouple hardware implementation details
from the programming interface.

Yes, I suppose I could implement completely seperate hardware drivers
with a consistent interface, and do away with the abstraction layer.
However, that leads to code duplication, which has its own downfalls.
Personally, if I had to pick one poison or the other I'd take
overengineering over maintaining divergent implementations, but the
patch apparently made my predeliction obvious :).

Thanks,
Brent Casavant

-- 
Brent Casavant                          If you had nothing to fear,
bcasavan@sgi.com                        how then could you be brave?
Silicon Graphics, Inc.                    -- Queen Dama, Source Wars

Re: [PATCH 0/2] external interrupts

[Andrew Morton]

Brent Casavant <bcasavan@sgi.com> wrote:
>
> On Sun, 21 Aug 2005, Pavel Machek wrote:
> 
> > > Here is a set of patches that implements an external interrupt capability
> > > in Linux, along with a device driver for a specific hardware device.  I
> > > submitted the patches several weeks ago, and they drew no comments, which
> > > I take to be a good sign.  Anyway, I'm 
> > It was not good sign in this particular case. My reaction was "this is _so_
> > overengineered tjat he's probably joking".
> 
> Laughter was not wholly unexpected, though I wasn't joking.  I'm trying
> to be realistic about the lifetime of any given hardware, and IOC4 is
> several years old at this point.  Couple that with a sincere desire to
> preserve application source compatability when (not if) new hardware
> appears, and an abstraction layer seemed to be a logical choice.  I'm
> more than happy to discuss problems in the abstraction layer's interface
> and make appropriate changes -- I'm nothing if not obliging.

Having an abstraction layer for a single client driver does seem a bit
pointless.  It would become more pointful if other client drivers were to
pop up.

Hence an option would be to merge an IOC4-specific driver which just does
what you need, no abstraction layer.  If someone later comes up with a
requirement for a driver for similar-looking hardware then we can resurrect
the abstraction layer at that stage.

Re: [PATCH 0/2] external interrupts

[Brent Casavant]

On Mon, 22 Aug 2005, Andrew Morton wrote:

> Having an abstraction layer for a single client driver does seem a bit
> pointless.  It would become more pointful if other client drivers were to
> pop up.
>
> Hence an option would be to merge an IOC4-specific driver which just does
> what you need, no abstraction layer.  If someone later comes up with a
> requirement for a driver for similar-looking hardware then we can resurrect
> the abstraction layer at that stage.

Agreed.  I'll look into what our plans are for additional or follow-on
devices.  Right now I see a need for this on the horizon, but it's not
much more than a tiny indistiguishable dot.  I'll have more info in a
day or two.  I'll also use that time to fix up the things that
Christoph Hellwig noticed.

Brent

-- 
Brent Casavant                          If you had nothing to fear,
bcasavan@sgi.com                        how then could you be brave?
Silicon Graphics, Inc.                    -- Queen Dama, Source Wars

Re: [PATCH 0/2] external interrupts

[Christoph Hellwig]

On Mon, Aug 22, 2005 at 02:43:30PM -0700, Andrew Morton wrote:
> > Laughter was not wholly unexpected, though I wasn't joking.  I'm trying
> > to be realistic about the lifetime of any given hardware, and IOC4 is
> > several years old at this point.  Couple that with a sincere desire to
> > preserve application source compatability when (not if) new hardware
> > appears, and an abstraction layer seemed to be a logical choice.  I'm
> > more than happy to discuss problems in the abstraction layer's interface
> > and make appropriate changes -- I'm nothing if not obliging.
> 
> Having an abstraction layer for a single client driver does seem a bit
> pointless.  It would become more pointful if other client drivers were to
> pop up.

The Octane port will hopefully soon support external inteerupts on the
ioc3, so this does make sense.

[PATCH 0/2] external interrupts

[Brent Casavant]

Hello,

Here is a set of patches that implements an external interrupt capability
in Linux, along with a device driver for a specific hardware device.

External interrupts, in short, encompass the ability to respond quickly
via an interrupt routine to an externally applied voltage signal.  This
finds use primarily in real time systems which must react to an event
generated outside the computer.  External interrupts also encompass
the ability to generate such signals in order to notify other computer
systems (or even the same system, depending on cabling and configuration)
of an event of interest.  This is explained in greater detail in the
Documentation/extint.txt and Documentation/sgi-ioc4.txt files which are
part of these patches.

The first patch implements an abstraction layer which creates a sysfs
class "extint".  This class provides device control via several (hopefully)
common attributes of an external interrupt device.  For example, an
application can control the source of ingested interrupts if multiple
input jacks are present on the specific hardware, or control the output
waveform and repetition period on the output side.  Mechanisms are
provided to allow a low-level driver to enumerate these capabilities
where appropriate.

This first patch is motivated by several factors.  The first is a clean
seperation of device-specific knowledge from the more general concept, thus
isolating applications from needing to be aware of device characteristics.
The second is the simplification of low-level external interrupt drivers
by centralizing the common factors (e.g. a global counter, a list of
actions to invoke at each interrupt, etc) in the abstraction layer.
Finally, it enables easy support for additional or alternative low-level
(i.e. device-specific) external interrupt drivers in the future.

The second patch implements the low-level external interrupt driver for
the SGI IOC4 I/O controller chip.  For the most part this driver simply
registers itself with the extint abstraction layer, and of course takes
care of all the hardware bit-twiddling to effect appropriate operation.
In addition, this driver provides its own character special device which
can be mmap'd directly into the user address space.  This provides the
ability to control interrupt output generation without going through
the abstraction layer's sysfs attribute's read/write routines by directly
poking values in the appropriate hardware register (which lives in its
own page of memory seperate from all others).  This capability enables
the application to more expediently generate output where this bit of
overhead might matter (remember, this is typically used in real time
or near real time systems).

I do realize this whole thing is slightly overengineered if only to enable
the IOC4 device's external interrupt capability.  However, like all
hardware, someday IOC4 will be a long-forgotten memory, and SGI (me in
particular) would like to put a suitable mechanism in place to enable
different types of hardware with similar capabilities in the future.
Hopefully any interested third-party hardware vendors will add their
own low-level external interrupt drivers.

And while I mentioned real time as the primary application of external
interrupts, I'm sure there are other creative uses to be found.  My
imagination, however, is limited. :)

Brent Casavant

-- 
Brent Casavant                          If you had nothing to fear,
bcasavan@sgi.com                        how then could you be brave?
Silicon Graphics, Inc.                    -- Queen Dama, Source Wars