[parisc-linux] SuckyIO support

[Grant Grundler]

Matthew Wilcox wrote:
> On Mon, Dec 25, 2000 at 11:16:24PM -0800, Grant Grundler wrote:
> > INTERRUPT_PIN is zero for function 0 and 1. And according to PCI spec,
> > suckyio function 0 and 1 can't won't generate interrupts regardless
> > of what's in INTERRUPT_LINE.
> > I don't want to write/modify/support code that implies otherwise.
> 
> I thought it was understood that this device was not PCI-conforming?

Absolutely correct.

> That it did generate interrupts for functions 0 and 1.

Not directly. AFAICT, subdevices can only generate interrupts via 8259
which lives on function 1. And it looks like *none* of the functions
under suckyio implement INTERRUPT_PIN register. *sigh*

The INTERRUPT_LINE cfg register just happens to live under function 2
but could live in any of the three functions. Suckyio provides this
register merely as a convience to the BIOS/OS programmers.

> Could we nail
> down exactly _how_ this device generates interrupts for the serial & ide
> ports?
...

IRQs for all devices we care about are routed through the on-chip 8259's.
Master 8259 output is routed to INTERRUPT_LINE 0 of the parent IOSAPIC.
I can't tell if that's through CPUINT or INT[A-D] or what.

BTW, I suggest suckyio get it's own IRQ region to manage the 8259's.
Here are more notes:

 *      Most interrupt sources can be routed (or mapped) to interrupt pins on
 *      the 8259.  The available pins are (15-14, 12-9, 7-3, 1).  The following
 *      pins are dedicated.
 *
 *              Timer Out0        Channel 0
 *              8259 cascade      Channel 2
 *              Real-Time Clock   Channel 8
 *              Coprocessor Error Channel 13
 *
 *
 *      There are only 6 interrupt sources supported at this time.  These
 *      take up all the available interrupt sources on the master 8259.  The
 *      slave mode code has not been tested completely because we do not use
 *      it.  Note that the interrupt sources are given fixed interrupt routing.


FYI - The 8259 "fixed" routing used by HPUX is below.
Though I have the impression PNP code could be used to assign
IRQ lines if one doesn't want another LASI-like IRQ scheme.

   switch (obj->suio_device_id) {
      case SUPERIO_ID_UART1:
        obj->suio_irq = 3;
        break;

      case SUPERIO_ID_UART2:
        obj->suio_irq = 4;
        break;

      case SUPERIO_ID_FDC:
        obj->suio_irq = 6;
        break;

      case SUPERIO_ID_PARALLEL:
        obj->suio_irq = 5;
        break;

      case SUPERIO_ID_USB:
        obj->suio_irq = 1;
        break;

      case SUPERIO_ID_IDE:
        obj->suio_irq = 7;       /* XXX IDE has two channels? */
        break;

      default:
        VASSERT(0 == 1);
    }


> > We'll end duplicating much of what's in the generic PCI code basically.
> > You can understand why I might be less than enthusiastic about this idea.
> 
> Yes.  OK, better idea: we can do the quirk fixup in the PCI_FIXUP_FINAL
> pass instead of the PCI_FIXUP_HEADER pass.  This is called after the bus
> fixup code has set ->irq.  Of course, this might be completely the wrong
> thing to do... I really need to know the answer to the above question.

This does sound better given suckyio doesn't support INTERRUPT_PIN.

The fixup code could use Function 2 INTERRUPT_LINE to determine which
iosapic input line is being used (instead of assuming line 0). I'm thinking
we need to add another iosapic_fixup()-like interface so PCI quirks code
will correctly register suckyio's INTERRUPT_LINE. I'm trying to keep the
method iosapic virtualizes IRQs with private to iosapic.c.

thanks,
grant