cvs commit: src/sys/alpha/alpha interrupt.c src/sys/alpha/isa isa.c src/sys/amd64/amd64 intr_machdep.c src/sys/amd64/include intr_machdep.h src/sys/amd64/isa atpic.c src/sys/arm/arm intr.c src/sys/dev/sio sio.c src/sys/dev/uart uart_kbd_sun.c uart_tty.c ...

[Bruce Evans]

On Fri, 28 Oct 2005, Warner Losh wrote:

> From: Gleb Smirnoff <glebius at freebsd.org>
> Subject: Re: cvs commit: src/sys/alpha/alpha interrupt.c src/sys/alpha/isa isa.c src/sys/amd64/amd64 intr_machdep.c src/sys/amd64/include intr_machdep.h src/sys/amd64/isa atpic.c src/sys/arm/arm intr.c src/sys/dev/sio sio.c src/sys/dev/uart uart_kbd_sun.c uart_tty.c ...
> Date: Fri, 28 Oct 2005 20:02:18 +0400
>
>>   John,
>>
>> On Fri, Oct 28, 2005 at 10:41:42AM -0400, John Baldwin wrote:
[peter wrote]
>> J> > Of course the real challenge is to make things like the puc device do
>> J> > the right thing automatically instead of needing 'options
>> J> > PUC_FASTINTR'.
>> J>
>> J> You mean like sio(4) tried to?  The problem is that with the previosu code if
>> J> sio(4) went first, it would register INTR_FAST and some later PCI device
>> J> wouldn't be able to register its interrupt.  There's not an easy solution to
>> J> that problem if you want to keep the semantics that INTR_FAST implies
>> J> INTR_EXCL.

sio never tried to handle this.  It just expresses its preference for
INTR_FAST by trying for INTR_FAST first, and then expresses its capability
of not using INTR_FAST by retrying without INTR_FAST.  Higher layers
have no support for allowing drivers to do the right thing, which is for
the drivers to make just 1 call to bus_setup_intr(), with preferences
and capabilities expressed in the flags, and higher layers wiring the
interrupts dynamically so as to satisfy the most preferences while staying
within capabilities.

The PUC_FASTINTR hack handles this poorly.

The CY_PCI_FASTINTR hack handles this poorly, but not as poorly as the
PUC_FASTINTR hack since it has a smaller scope.  The log message that
added CY_PUC_FASTINTR points out part of the problem fixed in this
commit:

% RCS file: /home/ncvs/src/sys/dev/cy/cy_pci.c,v
% Working file: cy_pci.c
% ----------------------------
% revision 1.10
% date: 1999/01/15 10:00:12;  author: bde;  state: Exp;  lines: +13 -2
% branches:  1.10.2;
% Use a fast interrupt handler for the PCI version of the cy driver
% if option CY_PCI_FASTINTR is configured and mapping the irq to a
% fastintr is possible.  Unfortunately, this has to be optional because
% pci_map_int_right() doesn't handle the INTR_EXCL flag right --
% INTR_EXCL is honoured even if the interrupt needs to be non-exclusive
% for other devices to work.
% ----------------------------

>> is it possible to implement such a feature that driver requests INTR_FAST
>> and it succeds only and only if interrupt isn't shared?

This is exactly what we had.  It doesn't work...

> Not really.  The problem is that you don't know it is shared until it
> is too late.  You have no way of really knowing if a device uses
> interrupts until its driver attaches and requests an interrupt.  Given
> how we do our device probing, there's not really a chance to
> 'downgrade' the FAST to non-FAST later with driver notification (we
> can trivially downgrade what we do to ithread, but then the driver
> might not actually work).

Attaching the interrupt only at open time and detaching it at last-close
time would work OK, and is needed anyway to handle timesharing of normal
unshareable isa interrupts (RF_TIMESHARE is another problematic higher
level flag, since it doesn't do anything to make the necessary timesharing
actually work).  Problems with this:
- the console device now wants its interrupt enabled at all times, and
   doesn't tuen off the interrupt at the device level on close
- programs like getty would keep devices opened and would have to be
   killed to let the interrupt wiring change
- interrupt unwiring doesn't work right, partly due to supporting
   historical braindamage in ppbus.  The interrupt thread should go away
   on the last detachment from it, but doesn't.  ppbus sets up and
   tears down its interrupt for every user-level i/o, since its
   timesharing involves a sort of open/close for every i/o.

RF_SHAREABLE is another problematic higher level flag.  sio doesn't set
it for the interrupt resource, so the interrupt should be unshareable,
but interrupt sharing works anyway.

Bruce